Hacker Newsnew | past | comments | ask | show | jobs | submit | manquer's commentslogin

Eutelsat Oneweb is a subsidiary of Eutelsat group which after the bankruptcy, merger and capital raises currently composed of

- French state(29%),

- Bharti Airtel -Indian telecom group (17%),

- UK government (10%),

- SoftBank (10%) -Japanese bank

- CMA CGM(7.5%) french shipping company

- a consortium of French insurance companies with 5% .

Till recently a South Korean conglomerate Hanwha also had 5% stake .

there is a significant concentration of holding by national governments, UK do have a golden share protecting their strategic needs , but their investment is now a small minority.

it is mostly French company today with diversified direct interests from 4-5 major countries.


Unicode emojis aren’t ascii .

Long before Unicode points were assigned we were using emojis in text communication in email and sms.

you can always be quite expressive with ones like :) :D :-( or even ¯\_(ツ)_/¯ - although not strictly ASCII.


Those are called emoticons, not emoji. "Emoji" came about specifically to distinguish the single-character ones (unicode or proprietary) from what we did before.

Monorepos , or rather in large enough codebases work can tend not to overlap

More people spent lot more time learning new tech skills (at every experience level).

The excess time available (less commute or career pause etc) and more interest (much more new opportunities) were probably leading reasons why they spent more time I would imagine.


I’d guess it’s also because it’s not as easy to ask your random question to a coworker when they’re not sitting next to you in the office.

I felt it became easier with slack.

The culture to use slack as documentation tooling can become quite annoying. People just @here/@channel without hesitation and producers just also don't do actual documentation. They only respond to slack queries, which works in the moment, but terrible for future team members to even know what questions to search/ask for.


> BYD at with FSD?

Setting aside the performances of similar systems, the more fundamental question is why is this even important to Chinese carmakers?

1. They are shutout of the U.S. market with tariffs from both parties, that doesn't seem likely to change.

2. Self driving systems are far more difficult to work well on the roads of Europe, Asia or Africa. The kind of wide roads and planned development only exists in U.S, Canada or Australia. On top of it the issues with weather handling are still on-going problems.

3. Labor is not near as expensive as in the U.S. in the rest of the world (dollar is expensive) so automation ROI is not as attractive given the costs.


Tesla was a third of the new car market in Norway last year, but most people buy without the FSD. I don't know anyone that drives around using FSD as anything other than a gimmick or glorified lane assist.

Isn't that the model of every private equity? It was always hard to do well.

Although it doesn't seem that way, there are lot of companies that have become large recently, it is best time ever historically for companies to be able to grow large quickly much more so than 50 years ago in the early days of BH.

There are 1000+ unicorns today, about 50 of the fortune 500 are founded > 2000, a large number of companies that have chosen to remain private with revenues in excess of >$10B like Stripe or SpaceX etc

While it is true that lot of the action has been in sectors BH has never been comfortable holding large assets in such as SaaS, new fin-tech(i.e. crypto etc), or gig econ(Airbnb/Uber etc), social media(tiktok et al.) etc, that doesn't mean the principles are no longer needed or there aren't opportunities to take stake in these now mature companies and drive value.


Unlike other SaaS "acquisitions" of late, this will be not as straightforward closure of a subscription business.

The $1.5B contract with the Saudi Arabia is substantial and investors will want that monetized too, there are also existing DCs GroqCloud have in the ME region and also other spots around the world that are quite valuable for their hardware and power agreements etc.

Nvidia has CIFUS and other regulatory concerns and also don't want to compete against their customers be a neo cloud provider, the Saudis likely still want their DC build outs to proceed.

All this to say, the remaining parts while no longer as glamorous is still worth a lot and cannot be easily sold to big tech co. GroqCloud is more be like Nokia Technologies/ Networks rather be killed.

---

As a result, staff not part of the Nvidia deal likely have solid jobs and also now the opportunity to climb the ladder quickly now that a lot of leadership positions have opened up.

They are also going to have to be compensated higher in cash or poached by an upcoming chip startup as they are no longer tied to equity options vesting scheduled of a very valuable company (Pre deal Groq or now Nvidia).

In any scenario they will come out better of the deal, not as much they could have in a full acquisition yes, but certainly better than most engineers not working for a hyped AI startup nonetheless.


It’s always faster and easier to copy than create(AI or not). There is lot of thought and effort in doing it first, which the second team(to an extent) can skip.

Much respect to what have you have achieved in a short time with graphite.

A lot of B2B SaaS is about tones of integrations to poorly designed and documented enterprise apps or security theatre, compliance, fine grained permissions, a11y, i18n, air gapped deployments or useless features to keep largest customers happy and so on and on.

Graphite (as yet) does not any of these problems - GitHub, Slack and Linear are easy as integrations go, and there is limited features for enterprises in graphite.

Enterprise SaaS is hard to do just for different type of complexity


I think trivial GH integrations are easy.

If you've used Graphite as a customer for any reasonable period of time or as part of a bigger enterprise/org and still think our app's particular integration with GH is easy... I think that's more a testament to the work we've done to hide how hard it is :)

Most of the "hard" problems we're solving (which I'm referencing in my original comment) are not visually present in the CLI or web application. It's actually subtle failure-states or unavailability that you would only see if I'm doing my job poorly.

I'm not talking about just our CLI tool or stacking, to clarify. I'm talking about our whole suite, especially the review page and merge queue.

What kind of enterprise SaaS features do you wish you had in Graphite? (We have multiple orgs with 100s-1,000s of engineers using us today!)


The Graphite review UI/UX is at least 3x better than GitHub, and also somehow loads faster. Same with the customizable PR inbox. Love it! Appreciate your work on the platform!


> abhorrent and downright abusive move

Is it that egregious?. I read it as they are redistributing the costs. It is in combination dropping the managed runner costs by a good margin and charging for the orchestration infrastructure. The log storage and real time streaming infra isn't free for them (not $84/month/runner expensive perhaps but certainly not cheap )

We don't need to use the orchestration layer at all, even if we want to use rest of the platform, either for orchestration or runners. Github APIs have robust hooks(not charged extra) and third-party services(and self-hostable projects) already provide runners, they will all add the orchestration layer now after this news.

--

Competition is good, free[2] kills competition. Microsoft is the master of doing that with Internet Explorer or Teams today.

Nobody was looking at doing the orchestration layer because Github Actions was good enough at free[1], now the likes of BuildJet, Namespace Labs etc are going to be.

[1] Scheduler issues in Github Actions not withstanding, it was hard to compete against a free product that costs money to build and run.

[2] i.e. bundled into package pricing,


I can definitely hope for more competition and new providers, yes - good point


OP means to say he has many jobs in the merge queue that the runners are always busy 24/7.

This is not uncommon in some orgs - less number of concurrent runners, slow builds, loads of jobs because of automation or how hooks for the runners are setup.

In the context of discussion that doesn't matter, OP's point distills to that they use minimum of 720 hours / month of orchestration time or some multiple of that on self hosted runners running 24x7.

Github will now charge $84 extra per month for single self-hosted runner running 24x7 - i.e. that is the cost for 43,200 build minutes for only their orchestration alone.

In a more typical setup that is equivalent to say 5 self-hosted running running ~4.5 hours a day(i.e 144/hours/runner/month)


If you have a lot of not very time sensitive jobs, e.g. large merge trains, it was reasonable to have a not very fast runner run close to full utilization. Now that you'd pay by the run-minute, it'll be cheaper to move to a faster runner and run it at 10%.


OP replied and clarified that that's not the case.


His workload is close to the more typical one i mentioned as scenario b. It will cost them $84/month.

For me, we do about 800,000 build minutes/month, for orchestration alone it is going to be $1600/month. In contrast the runner host we use (Namespace labs) cost $0.0015 / minute[1] which is less than orchestration cost for GH, that is just ridiculous.

---

[1] It is even worse, the first 250,000 minutes is fixed at $250, so the base is $0.001 /minute for the runner.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: