There is a type of videos, where people mock US-citizens for their ignorance about the rest of the world and how things are working there. Those mocking EU for their efforts, usually have that same smell.
HN is full of people which EU is fighting against, so of course is there little chance to find sane discussions here. You could try some european subreddits, or local tech-sites from Europe, there is usually a better chance to find people who benefit from EU-regulations and have a more rational view on them.
KDE4 killed too much momentum; many promising features and apps disappeared for whatever reason or slowly faded out into irrelevance. Stuff like KIOSlaves is still around, but never really evolved beyond what it was 20 years ago.
Isn't Trinity just maintenance and small improvements of KDE3? I don't remember to have heard about any revolutionary changes, or even just significant evolutionary improvements.
Definitely not revolutionary. Plenty of evolutionary changes - because linux itself has changed. the last major release brought
- LUKS encrypted disk support desktop-wide,
- storage device hot plug/unplug
- new Bluetooth GUI (tdebluez)
- new media player (kplayer),
- PulseAudio support
- window tiling
A good mailclient allows a skilled user a much more efficient communication than most forums.
> It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else.
True, external moderation is a benefit of centralized platforms, but a mailclient allows personalized moderation, which allows with a well organized list to only filter out anything you are not interested in. Usenet had the benefit of both, a centralized platform with moderation, and powerful clients for further personalization. Too bad it died for most usages.
I would assume they have built some key problem-solving skills that can be valuable. Training in tooling is much easier than building the right mindset.
> Kids these days... Why would someone in their right mind think working on the Voyager project could damage their careers?
It's an isolated legacy-project with no future. Mostly everything you learn for it will be only useful for this specific project, so all time to invest there is time to can't invest into something useful. Sure, there are probably some parts to learn from this too, but It's less than what your competitors will learn on their fancy modern projects.
> You can work on new and fancy tools all you want to improve supporting tools
Voyager is in maintenance, there is no big innovation or big progress to be made there. It's just work to hold the line as long as possible. And I guess nobody want's to be the one killing it because of a poor attempt to innovate something.
You should hire for personality characteristics, not knowledge. I'll take anyone who's worked on a weird obscure system and figured it out from first principles over Front End React Dev #8482828 with Opinions on algebraic effects.
> You should hire for personality characteristics, not knowledge.
I'm not sure what personality characteristic are supposed to be in this context. But if you mean skills, then you have a false assumption. NASA and the surrounding industry is not really the environment where they grow boring react devs. For every legacy project like voyager, they have a dozen frontier-projects and other weird obscure jobs where one can gain the same skills, but better, with more potential for further growing. And someone early in their career will naturally choose something with more potential for their future.
Understanding assembly language (any architecture) give insights into how computers work that are still valuable and relevant today. Almost nobody still writes code in assembly, but understanding it at least conceptually is still worth something.
If I were hiring, I would almost always prefer a candidate who had some experience at machine/assembly programming to one that didn't, all else being roughly equal.
I've been a developer for 20 years, I do some reverse engineering stuff on the side using assembly.
There hasn't been a single time in 20 years that it was actually relevant for real work in any way.
Unless you are doing very specific work knowing assembly is about as useful as knowing COBOL (which is also useful for a very specific kind of work that most devs will never do)
Learning new and weird things builds brain elasticity and vocabulary for you to express new ideas. I always recommend people to learn FORTH, or Lisp, or APL. Learn to think with different paradigms.
As an extracurricular activity sure, but if your resume just has FORTH on it recruiters are going to throw it in the garbage because there's no evidence you can work in a modern development environment
You don't need to push the needle as a junior though. It's a "completed project" where one can glean many insights. And the matter of transferrable skills is simply a matter of being able to say how what you learned applies in a different context. A useful skill in-and-of-itself
> You don't need to push the needle as a junior though.
Doesn't matter. Many young people have strong motivations to shine and push, especially when they are in high profile-jobs. Legacy-projects are simply not alluring enough for this.
Define quickly. The problems are known for 10+ years, the calling is around for even longer. Germany car-industry has been stagnating for decades, rotting through the system even today, years after all those crises have starting killing it.
No, there are never enough experts for everything. I mean, how can there ever be enough 18 year old workers, fresh from college, with 20 years experience on a technology which will only be released next month, who are willing to work for minimum wage and a rotten fruit basket while upskilling themselves in their own private time?
At the core, there is the tradeoff between ability and security. You can give the users power and enable them doing fancy shit, or you can make it secure, stripping any meaningful ability. Usually, people prefer ability over security.
The other problem is that security is hard, and just giving generic access and adding some basic guards is simple.
The first trade-off is not precisely stated, you can do "both" with user choice. In this case it would be: no plugin has "all filesystem access" unless user explicitly approves it, and that approval steers the user to a very narrow "plugin folder only" path by the way UI is done. Think this is "secure by default"? You don't undermine any ability here because most plugins don't need any filesystem access, so you get extra security "for free" for most of the users and with only some friction (but still not removing the ability altogether) for the rest.
reply