Airbus was never born as a European giant. It was a merging of many national champions (Aérospatiale, DASA and CASA) that were each already making full airplanes. They figured out how to spread out the manufacturing later.
Airbus currently has two factories finalizing the airplane assembly: one in Toulouse and one in Hamburg. You could copy this model and just open different fab in different countries to spread production.
Also, another model is one country making wafers, one country making EUV-lithography machines and parts, one country mining and refining silicon, etc.
There's no "one country making lithography machines". The mirrors come from Germany already. Other parts from about 160 other countries around the world. The EUV tech itself is an American invention and was picked up by ASML. That is why USA has the say in who gets it.
The poster is the author of the website. So I think it's self-promo mixed with "hey, look how interesting is the amount of 'bureaucracy' involved when one wants to move out of Germany"
I don't gain anything from promoting my free, hyperlocal content here, but I love to talk about my work and the discussion here is unfailingly interesting.
I liked it, even though I have no intention of changing my domicile from Germany.
The checklist somehow seems very German, including the advice that you don't have to turn in a resignation letter if you're fired. I know that sounds snarky, but the bureaucracy laid out is so vast it's actually warranted.
As a USAmerican though, I see it as more general—a statement about how modern, "1st-world" civilization has become so god-damned complicated.
I catch myself (especially since I have kids) realizing how difficult it is to navigate some aspect of modern life (for example, various payment methods—credit cards). A kind of mantra that always rises in my thoughts is, "No one would ever have designed the system to work like this."
Somehow, independent actors, independent reasons, likely the ability to make it this complex has indeed made it this complex.
It's no surprise then that just functioning in this modern society induces a level of background anxiety. Pretty much the opposite of "touching grass".
> “AI makes it easier”, was it hard to stumble across out-of-context clips and photoshops that worked well enough to create divisiveness?
Yes. And I think this is what most tech-literate people fail to understand. The issue is scale.
It takes a lot of effort to find the right clip, cut it to remove its context, and even more effort to doctor a clip. Yes, you're still facing Brandolini's law[1], you can see that with the amount of effort Captain Disillusion[2] put in his videos to debunk crap.
But AI makes it 100× times worse. First, generating a convincing entirely video only takes a little bit of prompting, and waiting, no skill is required. Second, you can do that on a massive scale. You can easily make 2 AI videos a day. If you want to doctor videos "the old way", you'll need a team of VFX artists to do it at this scale.
I genuinely think that tech-literate folks, like myself and other hackernews posters, don't understand that significantly lowering the barrier to entry to X doesn't make X equivalent to what it was before. Scale changes everything.
Just have video cameras (mostly phones these days) record a crypto hash into the video that the video sharing platforms read and display. That way we know a video was recorded with the uploader's camera and not just generated in a computer software.
There aren't that many big tech companies that are responsible for creating the devices people use to record and host the platforms and software that people use to play back the content.
This is generated on device with llama.cpp compiled to webassembly (aka wllama) and running SmolLM2-360M. [1] How is this different from the user clicking on the link? In the end, your local firefox will fetch the link in order to summarize it, the same way you would have followed the link and read through the document in reader mode.
Like, can we all take a step back and marvel that freaking wasm can do things that 10 years ago were firmly in the realm of sci-fi?
I hope they’ll extend that sort of thing to help filter out the parts of the dom that represent attention grabbing stuff that isn’t quite an ad, but is still off topic/not useful for what I’m working on at the moment (and still keep the relevant links).
They should advertise that. I pretty much reflexively avoid any mention of AI in interfaces because they usually mean "we're sending this all to openthropigoogosoft so I hope you don't have any secrets."
One of these features is "Active Hood" or "Pop Up Hood" which uses pyrotechnic to pop the hood of the car in case of a frontal collision with a pedestrian, thus making the front hood of the car acting as some kind of stiff airbag for the pedestrian. This helps reducing the risk of life-threatening injuries. https://www.youtube.com/watch?v=q4zfwUL3joI
> Go 1.25 introduced a waitgroup.Go function that lets you add Go routines to a waitgroup more easily. It takes the place of using the go keyword, [...]
99% of the time, you don't want to use sync.WaitGroup, but rather errgroup.Group. This is basically sync.WaitGroup with error handling. It also has optional context/cancellation support. See https://pkg.go.dev/golang.org/x/sync/errgroup
I know it's not part of the standard library, but it's part of the http://golang.org/x/ packages. TBH, golang.org/x/ is stuff that should be in the standard library but isn't, for some reason.
I thought exactly the same thing. I use errgroup in practically every Go project because it does something you'd most likely do by hand otherwise, and it does it cleaner.
I discovered it after I had already written my own utility to do exactly the same thing, and the code was almost line for line the same, which was pretty funny. But it was a great opportunity to delete some code from the repo without having to refactor anything!
> and the code was almost line for line the same, which was pretty funny.
One of the core strengths of Go is that it fits the zen of Python's " There should be one-- and preferably only one --obvious way to do it" and it does this very nicely.
I never used errgroup but I realize that it's essentially the same what I end up implementing anyways.
With standard waitgroups I always move my states as a struct with something like a nested *data struct and an err property which is then pushed through the channel. But this way, my error handling is after the read instead of right at the Wait() call.
I would create an unwarranted bias towards people working for companies doing mostly opensource. If their previous job was writing safe code for rockets and airplanes, the candidate will very likely be qualified to write embedded code for tractor/cars but incapable of showing previous work due to confidentiality agreements.
I mean, I was hired out of university, and I had a portfolio of programming and a github ready to go to show that I could program, without having a previous job to show code from at all, let along one with an NDA
Do you have an updated portfolio though? For many people working in private industry, they aren't allowed to share code from their job, and their previous portfolio projects are from college, which would not be good enough for a mid or senior level role. Would you hire a (non-junior) frontend developer who shows you a React todo list they made 8 years ago?
You were young without kids or any other responsibilities, so you had spare time to nerd around. Not everybody is in that position. With this requirement you would create a bias towards single parents or folks talking care of the handicapped partner/parent, as well as another bunch of other categories of people.
Yeah, I'm confused by the article. Following this logic, any interview sucks because of the stress it puts on the candidate. So what am I supposed to do? Hire based on a home assignment? then the "unpaid labour" crowd will call me out, and I personally believe they would be right to do so... So I'm supposed to hire based on résumé only? It's a lose-lose situation.
It reminds me a professor who recently told me, regarding ChatGPT use in university: "we're receiving every week applications from foreign students written in perfect German, then when we schedule a call for an interview with the potential scholar, they're incapable to speak either German or English."
Not specific to you possibly, but how about interviewing based on what you do in this role, and what the person has experience in?
I'm personally done with frontend/UI development roles where the interviews expect you to "brush up on CS fundamentals" or "prep", and then they ask nothing about "here, make this UI", as if it's some side thing. And if you didn't "prepare" for their leetcode crap, they act like you are some huge liar/faker who's somehow been coasting for 15 years.
Lot of people are pretty decent at bullshit. And they can talk the shop well enough to coast for a while.
On other hand I wouldn't say it would be unreasonable for UI people to setup some basic UI or like that could be done fast. And then do some edits there. Even if it is just copying some toy project. Then again I am not sure what is the current state of fronte-end and how much crap you need to do basic UI.
Yeah I think there is a: "does this person get UIs at all, and like this type of work" filter that gets missed by some of these leetcode processes. Personally tired hearing "this guy ACED the interview, a++++" then they fumble around with the actual work we have to do.
i agree. the stress is an unavoidable in any context where people are being judged or evaluated. i also find take-homes stressful, with in-person coding at least the stress is constrained to a narrow time window.
but i also think that that's why live coding can work really well with simple problems like fizzbizz, create a list of fibonaccis, etc. these are simple-ass problems that any coder can churn out in their sleep. if the stress of an interview prevents you from solving something like this... you probably need some more practice coding until something like this becomes easy enough to do under stress.
Another security article recommending fail2ban again... Please don't do this.
Run SSH behind some layer. Some people use Wireguard, and that's okay, I prefer spiped [1] because I can run it as an unprivileged user in a fully hardened systemd unit [2], and I can use ProxyCommand in my ssh_config, which makes it transparent: no need to be constantly on a VPN or to turn it on, I just ssh.
This guide recommends two-factor authentication, which IMHO is overkill and lowers your server reliability by using some random pam authentication modules. Also your spiped key (or your wireguard key) can be considered a second factor authentication.
And a second independent layer lowers the probability of being vulnerable to a 0-day vulnerability on SSH [3] or to Jia Tan [4]
fail2ban means you have a daemon running as root parsing random logs and modify your firewall rules... Yikes... [5] If you're concerned about bruteforce bots, they'll go away as soon as SSH behind something. Also with that layer, you don't need to make you firewall dynamic.
[5] Yes I know, you can use as a user, and modify the firewall rules with custom script with an SUID. But nobody does this, actually this guide doesn't do this at all, just everything as root!
Airbus currently has two factories finalizing the airplane assembly: one in Toulouse and one in Hamburg. You could copy this model and just open different fab in different countries to spread production.
Also, another model is one country making wafers, one country making EUV-lithography machines and parts, one country mining and refining silicon, etc.
reply