2,319 karma · joined September 13, 2018
Practically, they barely pay anything significant.
The lower net salary in Europe / Asia associated with rather high local tax means that most Americans citizens oversea barely own anything significant back to the state.
However it does remain an annoyance to fill the tax declaration every year: I know several American who chose to give up their citizenahip just to avoid this specific issue.
Then you are misinformed.
Because it happens continuously.
Canton executive argumenting again "conseil fédéral".
Local Syndic (Mayor) arguing against Canton decision.
Local parlement trying to address or delay legislation or arguing against Berne ones.
Just open a random news paper.
This is democracy, like it or not.
We live in a world where free open weight-models become competitive with frontier model within a year or two.
It is much more lucrative and proficient in term of business to solve real problems affecting the industries / govs with A.I right now than it is to do the arm race with OpenAI or Anthropic.
That is what Mistral is doing and that served them well so far.
The problem is not regulation and never has been. Regulation is a best a minor stone in the shoes of A.I company in Europe.
The problem is somewhere else: People fails to understand that there is no equivalent in the EU to the unlimited money tap of American VCs and private funding. That's just not a thing here, the investor landscape is much more dry.
Company here just cannot stay unprofitable for 25y while surfing on stocks valuation, it does not work like that in the EU.
And as such they cannot compete with behemoth like OpenAI that burn 80B$ a year of cash while staying afloat.
I do believe the approach of Mistral is the right one: Solve actual problems right now even if not Edge and construct on top of that.
Specially if politically speaking, the White House administration continue to give excellent arguments in favor of sovereignty for the incoming decade. It might be the best strategy they have.
Nor can Switzerland. And still it is one of the best country world wide both in term of living and economically.
Distributed federal power like Switzerland trades quick decision making for resilience.
If it might look up 'messy' on the surface, it is in fact a quality. A very valuable one in fact: because it is exactly what prevent fucked up like Trump to happen in the EU.
It was in the 2000s but not anymore.
If you go to eastern Europe, specially in the Balkans, you will see a lot of taxi drivers with Renault with milages over 500k km. They do hold the space with the usual Toyota Prius.
The current brands in the EU with bad reliability issues are Stellantis with infamous Puretech engine. And BMWs, not so much for the reliability aspect, but due to the stupidly high service costs.
"Frequent" is all relative.
The Renault Zoe, 10y ago, was already using a synchronous engine with wired rotor. And most were going over 150kkm without any issues nor brush changes.
> because the electrical currents that circulate through the rotor windings must generate heat
Currently stator heat in wired synchronous engine is less a problem than in SynRMs with permanent magnets.
Most neodymium based permanent magnets start to be irreversibly damaged id they heat up beyond 100°C. That's currently why Tesla has such a good cooling system in their engine.
Wired rotor are bunch of copper coil, as such they are much more resistant to temperature gradients.
> Some good old habit from C can still be positively used in C++, like the void* pointer and the size parameters.
That's garbage.
There is a clear interest of passing both size AND pointer in a single parameter like `std::span<std::byte>: It bind both value together and guarantee that you do not mess with the size of your buffer.
Pass "data" and "size" parameters through a chain of 5 function calls and there is a non-null probability that you passed "other_size" instead of "size" somewhere. This pattern happens everywhere in old C codebase and has been the source of countless security vulnerabilities and random buffer overflows for decades.
All modern languages (including freaking minimalist Golang) have now a "slice/span" concept built in.
It is not just to annoy programmers (and allow them to complain about 'complexity' in blog posts) but because it is a major improvement in term of memory safety and in term of reducing user errors.
> It seems that some people are really losing the taste for good readable code.
If 'span<std::byte>' or 'span<char>' are unreadable for you. The problem is not span, the problem is you.
These are concepts that has been existing for decades in almost all modern programming languages.
Even in conservative C++, it exists since 2014 in the GSL, in Qt and in boost.
And the interface is no different from vector...no excuse here... It is itself the most basic data-structure in C++.
> Why should people complexify and uglify their C++ code with the uint8_t pointer (or std::byte), when void* works just fine??
Sure. Let's extend the logic: I do propose also to replace all typed arguments with a void* pointer.
Because after all: 'It will just works fine' right ?
Type-safety and clear interface are overrated, we could all use only bytes and remove interface all together to get a closer experience of Fortran 77.
/irony
> Or maybe something even more complicated, like this? > template <typename T, std::size_t N> void DoSomething(std::span<T, N> data)
First that is non-sense.
If you want to pass a mutable buffer of byte, the correct signature is:
``void DoSomething(std::span<std::byte> data)``
There is no need for template signature here. You are making things up.
Second, there is also no need for the N parameter
``span<Type,N>`` is only used when enforcing a buffer with its size known at compile time is desirable. It can be for vectorization (e.g buffer is a multiple of the SIMD line) or to make it explicit in the interface (e.g for bloc cipher for instance)
> states that the pointer points to input read-only memory (_In_reads_)
You do that by using `std::span<const std::byte>` in any C++ codebase.
The fact he brags about that as "an advantage" for separated parameter passing just show currently how little is known here.
> My Pluralsight Courses
The kind of C++ code proposed in this blog post would be straight be refused in any PR in almost any serious organization with a proper review process.
So bragging about it on a blog while proposing some C++ teaching is audacious to say the least.
> To finish on that.
The sad thing is that there would be very valid criticism on `std::span<std::byte>`:
- Span does not do boundary check on access by default. Which is a bad design decision in 2026.
- It has an impact on compilation time due to the header inclusion
- std::byte is annoying to work with because it is a hack around an enum instead of a proper C++ builtin type.
But the blog post misses all these points entirely and sticks to complaining about 'Old C being better' the same way your family Grand-Uncle still brags about 'lead gasoline being better' for his 70s Pontiac.
Your credit card protect you against nothing. Reimbursement in case of fraud is not fraud protection, it is just bare minimal customer service.
In fact, the first thing your bank will do when your credit card number has been leaked and was used for a fraud... is to replace your credit card.
Because they know that, when the number is in the wild, it will happen again. The system is inherently insecure in case of dataleak.
Visa and Mastercard spent decades and millions constructing systems like "3D secure" supposed to protect again that by enforcing external authentication factors. But since the system is not enforced in every country, it is still a problem today.
Critical data is always better in the hand of a few (trustable) than in the hands of many.
That is currently the exact reason why you are using Paypal instead of giving your credit card number to everybody.
That is the exact reason why you are using a password manager.
A lot about security is about who you trust, and for how long.
I disagree. It has already severe effects.
- The fact we are facing so many data leaks made easy for malicious agent to cross and mix data sources and setup much more evolved and convincing scam scheme.
It is now trivial to get name, address, birthday and phone number from a data leak and crossed check that with the login id (email) used for lets say, a financial service and setup a convincing phone scam on that.
Many dubious actors are already doing that. One acquaintance of mine (working in ITsec ironically) got trapped by this exact scheme last week.
- It is trivial to harvest data leaks for online telemarketing, robot calls and any other abusing commercial practices.
- We are heading to a situation where any wierdo or/and stalker with a bit of tech knowhow can rather trivially extract a physical address out of an online profile. That is a giant opened door for harassment and physical insecurity for the most vulnerable of us.
Thats not just "nerd concerns" and the strategy "everything you do online is public" does not work. Many website will request my personal physical address for trivial matters like billing or delivery. That can not under any mean be considered public data.
I honestly tend to think this is the only viable long term strategy.
Let's face it: In a truly global internet where every single forum or website is hosted in a different country with a different jurisdiction, hoping that every single actor will act responsibly is just delusional.
It is not what we see. It is not happening and it is not going to happen.
Individual need to have right to online privacy.
That's means the right to get proxy email address, proxy phone number, proxy physical address and even proxy identity (first name/family name).
The sooner the governments will accept that, the better.
If done right, it is not incompatible with a system where identities can be reconstructed by the authorities for legal actions.
If nothing is done, scams and blackmails will continue to spread like bushfire and proxies anonymity will happen anyway outside of any control.
- CASTOR at CERN had also its disk centric derivative named DPM (Disk pool manager) that helped to power the LHC computing grid for multiple decades (WLCG) before getting deprecated.
- Interestingly DPM had an architecture quite aligned with the original Google File system even if developed completely separately: (One metadata node, multiple disk node. Design to do Write-once-read-many with very partial POSIX semantics).
- The LHC computing Grid is an association of research centers with their own infrastructure. As such, they had (historically) many diffent storage systems with diffent protocols and interface.
- To unify this madness, an attempt to do a "standard" protocol was made in the 2000s: the SRM protocol (storage resources manager). In a pure XKCD fashion, it went as bad as you can imagine. It tried to rely on the tech of the time (XML, SOAP, WSDL) and is a school case of terrible protocol design (bloated, slow, weak consistency, massive server overhead, stupidly complex to implement and quite insecure). The spec are worth a read if you want a good laugh [1].
- After 20y of struggle, SRM was eventually dropped for a more pragmatic and ad hoc solution based on HTTP + xrootd [2]. EOS itself uses xrootd quite extensively. (if this did not change)
- The history of computing at CERN is globally interesting because it is a pretty good image of the evolution of computing and of the "tech fashions" associated with it.
[1]: https://sdm.lbl.gov/srm-wg/doc/SRM.spec.v2.1.1.html
[2]: https://xrootd.org/
Quick tip for people that might encounter such situations:
- Phone to the emergency number. In Europe, it's 112. In France 15 is also working. Explain your situation (they generally do have English support).
- In many European countries, it is a Doctor you will have on the line. They can forward a medical prescription by email to the pharmacy close by.
- Even if you are not insured, the only thing it will cost you is the price of the medicine. For insulin, it variates from 20 to 40€ depending of the country.
- If you are over weekend or in middle of the night, in many EU countries have emergency pharmacy system. Some dudes somewhere on duty will open a pharmacy for you and you have to come on site.
If you are in France and if you wake them up at 03h00am, you can probably expect the legendary 'frendliness' (irony) of French customer service but at least you will stay alive.
Falcon has an accident rate of 2/640.
Airlines are about ~1.3 / 10^6
SpaceX first stage boosters are not orbital class.
They reach around Mach 6 (Up to my knowledge) at top course and around Mach 3 on descend before the landing burn.
Valid criticism however would be that the DC-X was intended for a return head first with a belly flip. Not tail first like SpaceX boosters.
As such, it is much more similar to Starship spacecraft.
Unfortunately, this is not the way the world is going right now.
Physics research, and generally speaking fundamental research, is publicly funded.
Meaning, most of the time, under funded.
We know how to do reliable vertical landing since the DCXA in 1991. Meaning more than 25y ago [1]
> reliability during missions (test explosions like this one are tests for a reason)
Static fire tests are routine since the 60s, nothing new here either [2].
> We have 15x reduction in payload-to-orbit costs
This is about manufacturing optimization and it has very little to do with rocket safety.
> hey are well on their way to making orbital space flight a commodity
They are not. It is at best marketing speech. The access to space is at best cheaper but will never be commodity.
The parent post is right on point: Rockets todays are still fundamentally the same giant bomb filled at 85% with explosive that we were making in the 60s. And this is unlikely to change and unlikely to ever be safe.
There is very valid reasons to that: we still did not find anything better than chemical propulsion to go in the last 80 years. It is the only 'working' solution in term of the energy density required to bring us there:
- Ion thrusters have amazing Isp but nowhere the Thrust/Weight ratio required to launch from Earth.
- Nuclear propulsion is good on paper but controversial in practice for pretty obvious reasons.
So we are still stuck. Stuck with burning 1'000t of highly inflammable Ergols in few minutes to just push any blob in orbit. With very thin engineering margins, way thiner than in airplane manufacturing or currently pretty any other domain.
And that make it unlikely to ever be really "safe" and accessible to the mass.
At least, not before we find a better solution to the problem.
> In modern AI clusters, the network is no longer just infrastructure sitting beneath compute
It always make me smile when someone is presenting these kind of topologies as "New", "Modern A.I" or anything remotely "Revolutionary".
The HPC domain and any decent supercomputers have been doing RDMA networking centered around "all-to-all" and "all-reduce" operations for at least 3 fucking decades now.
They are the main reasons supercomputers are almost always constructed around stupidly complex Torus or Dragonfly network topologies.
MPI itself has these primitives defined from v1.
The only difference now is that it switch from "This niche thing 3 nerds were using for weather simulations" to "this cool thing any hyperscaler NEED to have for *A.I*"
One is not exclusive to the other.
Skylon was expected to use air breathing engine up to Mach5+ and switch to rocket engine beyond it.
You can probably do the same for a suborbital airliner if you are insane enough.
Japan has a selective immigration system where the profiles JP gov considers as "necessary" are made easy to immigrate, and the others not so much.
One can disagree with the method, but at least it is consistent.
Near that, half of the American tech (and associated GDP) is constructed highly qualified immigrated engineers on H1B visas, and still the US gov openly shit on them.
> US system to apoplexy (i.e. language fluency requirements)
JP mainly just put some Japanese language level requirement on the HSP visas related to roles with communication. That honestly does not shock me.
Additionally, Japan has a very clear and straightforward process to convert HSP Visa (Highly skilled visa) to a permanent residency.
It can be done in 3years for most and to 1year for the high level candidatures (PhD profiles).
This is very far from the current H1B shitshow.
The debian project here acts as a counter-example: The institution governing the project far outlived its original creator and the "debian social contract" clearly helped to that.
Additionally, Infomaniak seems to have registered here as a Swiss "public interest" foundation. This has several implications:
(1) Swiss authority regularly audit the foundation and verify that there is no conflict of interests with the registered chart.
(2) Usage of the money should be done in respect of the chart.
(3) If any of the previous conditions is not respected. The Swiss authorities can step it and dissolve the entire thing or even take control.
Make sense.
Production price in Europe is between 3.5-4.5cts/kwh averaged. The rest are mainly transport and taxes.
If the EU currently choose to exonerate industrial consummers from these taxes and offload them on citizen (which honestly make sense from a business perspective), they could currently beat most US states in term of pricing while providing lower carbon footprint/kWh
There is plenty of vectorization that are simple enough to be done with std::simd today and that will still bring any autovectorizer begging on its knees for various reasons.
As an anecdote, I currently got a 8x speedup with std::simd (AVX2 & SVE2) on a rather trivial parser of mine recently that autovectorizer failed miserably to do properly.
Would I have get better result using intrinsics ? Likely, yes.
Did I want to suffer the maintainability and portability pain associated with it for a simple parser ? Certainly not.
For these use case, std.simd does the job. And will probably do a better and wider job with time when it get enriched by the committee.
The blog brings some valid criticism but really looks like a flame war trying to destroy an already opened door.
(1) Is there more performant solutions that std::simd for vectorization ?
Yes, of course. The STL evolves slow, its main goal is to provide a generic and portable implementations of a set of algorithms. Not to provide the best implementation in existence.
The best implementation of most algorithms (including SIMD patterns) evolves every 6 month, you can not expect a standard library with 3 different implementation to keep up with that.
(2) Is the future of vectorization ISPC ?
Nope. ISPC has been around for > 10y and is still niche. There is very good reasons to that: Yes it can generate better code but in most use case, adding a massive dependency of a compiler + an arbitrary LLVM version + a DSL on your project is not worth it.
Specially considering that it is an Intel project and that Intel (almost) abandonned the project multiple time (In pure Intel fashion).
So yes, criticism is easy, and yes std::simd is full of problems.
But I am glad it exists, and thanks to the people that made it happen... Because it is useful, even in the current state.
Europe is not Germany.
Electricity price is 2-3x times more expensive in Germany.
Electricity price for electricity intensive professional is around 12-14cts/kWh in France and can be reduce under 10cts/kWh for big consummers.
Which is competitive with the cost in several US states (it is still higher than Texas but not 3x).
Nordic countries should be able to align on that too.
Yes it is.
In most European universities, you will graduate in 3-4y.
And there is simple reasons for that: The funding associated with a Phd in many European country is 3-4y. So if you do not graduate, you actually become a burden for your lab.
And they do not need to.
There is already multi-platforms multi-languages package managers that do this job relatively well (Nix, flatpak, Guix, Spack (to some extend) ) and this is on that we should focus.
Passkeys absolutely do not need TPM.
You can get passkey support in any browser with a simple 1password plugin without any TPM hardware.
The same way you could get a TOTP app on your phone without any TPM.
TPMs are just an extra security layer for most usages.
They are mainly a necessity for some shady business like DRMs.
Pretty good example of what I name the "Small island problem".
And the main reason why I hate language specific package manager.
Phase 1- Every language try to reimplements its own package manager because it is seen as a "must have" for any modern language.
Phase 2 - The language specific package lanager is designed as if they live on a small isolated island. They do not try to integrate with other languages nor care about system libraries like OpenBLAS.
They do not manage properly versioning, diamond dependencies or ABI for basic libraries written in C C++, Fortran, Rust,....
Phase 3- the ecosystem grows up and the entire things blow up spectacularly in production due to the previously ignored problems.
The list of reasons can be pretty long: duplicated packages, ABI issues, portability issue, lack of sandboxing, poor system integration...).
Phase 4- Someone try to fix the mess by creating one more language specific package manager and we start again Phase 1.
And the problem is never solved because it is a structural problem and not an implementation one: At scale, language specific package managers are a terrible idea.
Taking into consideration the diversity of your ecosystem is not an option: it is a necessity.
Currently, the python and the JS ecosystems are beautiful examples of how far this madness can go.
To my understanding, they offer a full python compatibility but guide the user to something else.
For instance, Mojo itself is statically typed.