> It really is the case that a lot of incompetence is hiding in plain sight.
It may sound preposterous but I'm going to make the argument that sometimes not knowing how things work is a feature, not a bug.
I would assume most people with a little work-experience has encountered the kind of legacy systems which is crucial to the business, yet for whatever reason doing any sort of work on them involves a tremendous amount of friction.
A technical person who knows how this system works in and out will often claim that certain seemingly simple things cannot be done, because of how the system works.
It might be highly impractical, but if we're honest about things, it's all software. It can be changed if we decide to and the company is willing to put in the effort to make it happen. It's clearly possible, but the skilled worked will often present it as an impossibility.
The Julius, not hampered by such knowledge or constraints, will be see a seemingly simple problem, and maybe even imagine what other things would be possible or even "simple" if that problem was solved.
If the Julius manages to get management approval for these ideas, you may actually end up getting management approval for changing/upgrading the base system causing the friction, something the more fact-based engineers would not.
Chances are it's going to be messier than projected, not being delivered on time... But in the long term it might be a net good for everyone involved ;)
But that does not describe a Julius. Julius is not someone with an open mind unconstrained by technical debt, but someone who fakes an aura of knowledge while actually understanding very little.
There is a chasm of difference between an eager beginner who questions the way things work and how to make them simpler and someone who promises things which are impossible. Julius is the latter.
> All I want is init scripts and X11, but the horizons are shrinking. I've already compromised with systemd, and I don't like it. I see BSD in my future
Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Popular desktop environments are increasingly depending on Linux-only things. KDE has officially removed support for FreeBSD in Plasma login manager (because of logind dependency).
Gnome 50 plans to obsolete X11 completely.
If you want that simple, bright future of yours, you’ll have to fight/work for it.
> Freedesktop wants to kill X11 and are working continuously on that, to the point if rejecting patches and banning developers.
Are you referring to the developer of Xlibre, who submitted multiple broken patches & kept breaking ABI compatibility for little to no reason[0]? Or someone else?
I’m talking about that developer, yes. And I’m sure there’s more to the story than just ABI compatibility.
He wanted X11 to thrive. Freedesktop however has a goal for Wayland ultimately to replace X11, right? X11 should die. This is not hyperbole. It’s a stated goal.
So I think there’s more to the story than the simplified ABI aspect often mentioned here on HN.
We don't have to guess, the PRs & history are still there. You could easily go through them and find examples of the project members being unreasonable about ABI compatibility.
There is a difference of opinion. Freedesktop wants to "stabilize" X11. That does mean that they do not want to evolve Xorg. However, it does not mean that you cannot keep using it or that they are going to take it away. In fact, it is still being maintained and will be for a long time.
You can interpret the rejecting of patches and banning of developers as political. However others see the rejection and banning as protecting the stablity that is the goal.
If your goal is for Xorg to evolve and not to stabalize (fair), you may prefer Xlibre as a project.
Phoenix looks pretty cool too.
KDE Plasma and GNOME are trying to kill X11. Or, at least, they do not want to maintain support for it in their projecs. And COSMIC did not bother to add support for X11 at all. That will probably be the trend on desktop Linux.
My go to example would be long lasting issues with SMB support in Finder. All operations are very slow, the search is almost unusably so. The operations that are instant on every non-Apple device take ages on a Mac. I first ran into these issues 7 years ago when I set up my NAS, and they present to this day. I tried all random suggestions and terminal commands, but eventually gave up on trying to make it perform as it does on Linux.
With Apple's focus on cloud services, fixing the bugs that prevent the user from working with their local network storage runs contrary to their financial incentives.
Ubuntu releases supported (aka "really supposed to work") versions much more frequently than Debian, or I would have switched already. As it is, I just make the appropriate changes to purge Snap and run Firefox from a Mozilla apt repo and Thunderbird from Flatpak via Flathub.
You are talking about Debian stable which is released approximately once in 2 years.
People who want to have more (most ?) recent software on Debian should go for Debian Testing. Or Debian Sid, which gets upstream updates almost instantly but requires more Linux knowledge in case something gets broken.
Could this be due to how Windows vs Linux does process scheduling on CPUs with P- and E-cores?
To my knowledge Linux isn’t that capable on BIG.little architectures, and Linux power-management (as this intersects with) has always left a little to be desired - when comparing battery life to Windows.
Disclaimer: pure speculation. Possibly misinformed :-D
> To my knowledge Linux isn’t that capable on BIG.little
Android uses Linux as it kernel and runs on billions of devices with heterogeneous cores. Linux had this capability for way longer than Windows did; Windows for the most part did not run on devices with heterogeneous cores until the Intel Alder Lake (12th gen) CPUs.
Win11 outperformed Linux at Alder Lake release too [1] but eventually this changed and Linux was better on Meteor Lake [2]. Probably Arrow Lake has some microarchitectural changes which do not mesh well with Linux's core scheduling logic which Intel will need to fix, at which point Linux will probably close the gap again.
> Android uses Linux as it kernel and runs on billions of devices with heterogeneous cores. Linux had this capability for way longer than Windows did; Windows for the most part did not run on devices with heterogeneous cores until the Intel Alder Lake (12th gen) CPUs.
The extra capabilities of Android come from custom patches from Qualcomm kernels. They are so far diverged from the mainline, it is really really hard to merge it back. They not only add drivers but patch the kernel itself. Windows NT can have hints for thread scheduling from the userspace since they control Win32. Now the question becomes is there a way to patch Glibc and all other system libraries on Linux to give equal information to Linux kernel. Of course Linux kernel can guess but it is a lossy information channel.
Yep I suspect this too from the benchmarks. The linux kernel doesn't send the instructions to the right cores and likely sees them all as the same and not 'high power' vs 'low power' cores
> It sucks too. The way folks discover music is important. The convenience of streaming has lead to some interesting outcomes.
I think carefully curating music was something we did when music was a scarce commodity. Our collection was limited by how much we could afford to acquire. As such, acquiring the right stuff become a valued skill, not only for DJs, but for music enthusiasts just playing music at home.
Streaming killed all that. For 99.9% of the people out there, streaming has all they need and will ever need, at a fixed cost. It's absolutely abundance.
So the skill of curating music as a human activity went out the window as well, because there's no cost in playing the wrong track and deciding you didn't like it, before moving to the next item in your AI-generated playlist.
Put bluntly: How people discover music isn't important. At least not anymore.
That to me sound like a reason not to use this particular aspect of the AI hype.
We need to be better at controlling what AI does and how it does it, not giving it more leeway to do whatever it assumes makes sense.
reply