>In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.
> For those unaware, Linux has a very explicit policy of never breaking userspace
But has no qualm with constantly refactoring the kernel side of the coin for the most minor of reasons, which causes endless trouble when it comes to supporting out of tree drivers and is the true reason why Android will never be able to provide long term support. SOC manufacturers are not interested in the churn involved in updating their drivers to support the newer kernels that come with new android versions. Most often, it's because they want to keep their driver proprietary, but it is not the only reason, there is a cold hard truth about the nature of the market: new phones are released at a high cadence, while the process of mainlining a driver into upstream linux kernel is arduous, depending on the attitudes of kernel maintainers, truly painful, and no company out there could see any value in waiting for this process to end before releasing their hardware onto the market. Since they're already going to make it out of tree and release it as is, why would they bother? a year later, they'll repeat this process again, and again. Then Android updates, and the devices are obsoleted.
On the other hand, you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11. Windows doesn't constantly break your not-maintained-by-microsoft drivers with newer versions of their kernel.
It was such a terrible feature it was made optional in the C11 standard (you can be a conforming C11 compiler and not allow this feature) and will never, ever be implemented in a Microsoft compiler (while C is not a priority for MS, do note that they updated to C11 and C17).
> Particularly over the past several cycles there has been code eliminating the kernel's usage of VLAs and that has continued so far for this Linux 4.20~5.0 cycle. There had been more than 200 spots in the kernel relying upon VLAs but now as of the latest Linux Git code it should be basically over.
While I do agree that it is wrong to consider C++ a superset of C, it is time to forget about C99's biggest mistake and treat it as if it didn't happen.
Most are DIY, anything that is low wattage can be turned fanless if you buy some parts and build it yourself. But OP was daft with his answer. As someone who doesn't like the Apple ecosystem and only uses PC, I can only admit defeat when it comes to power efficiency. There is no way you could make a true fanless system run as well as Apple's efficient SOCs. PC parts that are as powerful generate a lot more heat and even with the best fanless cases and radiators there is only so much you can do to dissipate heat.
> I don't know of any IDE that provides even half of what i want TBH.
> On Linux (which is my main OS these days) pretty much all options involve a text editor
You obviously haven't looked hard enough.
CLion fulfills a decent amount of what you're looking for.
https://www.jetbrains.com/clion/
A lot more limited, but still much more capable as an IDE than text editors is KDevelop, for example your request here :
> (i haven't touched topics like VCS support and how i'd like to be able to see and use different version of the code from inside the IDE - like e.g. go back in time to a different function while the debugger is running - or anything that has to do with GUIs)
> An especially useful feature is the Annotate border, which shows who last changed a line and when. Showing the diff which introduced this change is just one click away!
Also example snippet of the debugging integration :
> You can also hover the mouse over a symbol in your code, e.g. a variable; KDevelop will then show the current value of that symbol and offer to stop the program during execution the next time this variable's value changes.
Many in very important subsystems. The XFS maintainer (who just recently stepped down from this role) and contributor Darrick Wong works for Oracle. Meanwhile, btrfs is the creation of Chris Mason, who worked there until 2012. Modern filesystems on linux owe a decent debt to Oracle. Good luck running an Oracle-free linux.
I often find it interesting when people imply the company is freeloading for having chosen the path of making an RHEL clone. They cloned RHEL because an unhealthy, dependent ecosystem was built around the one, singular linux distribution, not because they are unwilling to fund work.
Giving some serious competition to Red Hat can only be a good thing.
Sid is not, contrary to what others replied to you, a proper rolling distro. Particularly during the times when there are freezes for a new stable release, the repositories can become broken in a way that you may not be able to install software you want because its dependency chain is not fulfilled correctly. People who almost never install new software might not notice the issue, as it's not like sid will break what you already have installed -- as long as you don't say yes to a full-upgrade that shows a concerning amount of removals.
I've had experience with it and Arch in my rolling days (I am now a debian stable user, and use flatpaks and pet containers when I need newer software and feel much more at peace with my systems now), and Arch would, in my experience, never be the source of breakage. Things do break at times on a rolling release distro, but in the case of Arch, that would be because something upstream changed in their software, not because of the packaging of the distro itself.
Debian testing is not the answer either. When there are bugs that make it to testing, they can linger for an incredibly long time. At least, on sid, or Arch, it's more likely to happen, but also will get fixed quickly.
IMHO, the current landscape has solved the whole reason that made rolling desirable. With flatpaks and pet containers, there's nothing you could possibly miss, while you run a stable, unchanging system underneath. If you need support for hardware so bleeding edge that there isn't a backported kernel yet, I'd still find it less effort to package my own ( https://www.debian.org/doc/manuals/debian-kernel-handbook/ch... describes how to do this succintly. It's not as much work as it sounds ) from upstream until backport repositories support my hardware, than have a fully rolling distro on my computer.
> How's the vim ecosystem now? Is vimscript still dominant?
You can have a full neovim experience with all sorts of modern extensions without using a single line of vimscript. Some people even replace their init (neovim's vimrc) with lua, but I am of the opinion that it is a step too far, as lua isn't particularly adapted to writing configuration files and the result is too verbose to my taste.
> These projects are no joke and a few hurray contributors not lasting more than a couple of months won't cut it.
Those same contributors that remained on vim instead of neovim didn't put much effort into vim9 ecosystem either. I can't imagine them being willing to maintain all of vim's baggage when literally nobody writes vim9script. Classic vimmers tend to stick to the old vimscript.
As you said, contributing a few patches to classic vim is one thing, but becoming an actual maintainer of the behemoth that comes with a ton of useless baggage is a whole another thing. Maintaining a programming language no one uses.. sisyphus would be proud.
> Let's see how much traction Vimscript9 will get.
In practice, none. It's a wasteland. Extensions that aim to be compatible with both vim / neovim use the old vimscript, while lua has very, very significant traction in the neovim world among people who try to bring IDE like feature to vim. The amount of people willing to write extensions that only work on vim proper, which is what would happen if they used vim9script, is close to non existent.
I would not be so prompt to compare the situation with Apple and Jobs. Apple is a company that provides something no one else does while also holding a lock on its users. You can't go and install iOS apps on android.
On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim. I would not be very optimistic for the future of vim considering that nobody uses vim9script and that alone is quite the massive baggage to maintain, an entirely separate, new programming language? one that is used by.. no one? 99% of extension developers either use the old vimscript or lua, and neovim's lua base has significantly grown to the point where we can imagine a future that has no vimscript.
Where will they find people willing to continue working on vim's code base when it has this kind of really big, really useless baggage? and if they were to cut it out of the code base, would it still be vim? I respect Bram for his contribution to open source, and vim is one of my favorite, most used software, but his decisions in the past few years have been extremely poor and were not friendly toward the possibility of vim being community maintained.
> That's what set them apart, people wanted mp3 codecs and Nvidia drivers.
Oh, it was far, far more than that. For example, wifi support was still extremely immature when the first ubuntu releases came out and a lot of people made out-of-tree drivers to support the various wifi chips that were on the market. Out-of-tree drivers were not included in any distro but Ubuntu, and installing them on a distro like Fedora was a major pain, my laptop of the time depended on one of those drivers, the original developer probably got tired of the process of mainlining a driver and abandoned it and I had to modify the source code to adapt it to whatever API refactoring happened at the time on the kernel version used by Fedora to get it running. Running a roller like arch while depending on this stuff? ah, nonono.
By out-of-tree I don't necessarily mean proprietary driver, there were a lot of open source drivers that weren't mainlined, it was kind of a wild west.
It was also the first major distro to feature a Live CD installer. Sure, you could theoretically install LiveCD distros like Knoppix, but it wasn't recommended - and the desktop and assortment of apps lacked polish compared to what Ubuntu preselected.
It gave you a fresh debian system with recent packages without the breakages that happened routinely in sid (Ubuntu came out in an era where debian had major struggles with stable releases. These days it has gotten a lot better and I use debian stable now. Flatpak and containers also solved one of the pain points of LTS.)
As a long time linux user who started with slackware and the pain of configuring xfree86, the pains of winmodems and other hardware troubles of the past, I've come to appreciate polish and when Ubuntu came out I really liked it. The more the years come by, the less I want to fuss with my system. Ubuntu had a level of polish that was absolutely unmatched. These days, the differences between distros have massively shrank and I do not find Ubuntu any more convenient than regular debian and even arch isn't that harsh to use (though, after experiencing some package updates causing breakages I don't want to fuss with anything rolling anymore), but when Ubuntu came out, it was a revelation.
And the revelation lasted for quite a while, it didnt stop at the original release, because when Gnome 3 came out, it was incredibly barebones and painful to use (they didn't even want a menu entry to reboot your computer. Seriously. https://arstechnica.com/information-technology/2011/06/howto... "The developers argue that users should generally suspend their computers instead of shutting down." I mean, what the eff? ),
while Unity introduced really innovative features that I still miss to this day, like the global menu that allowed you to use functions from any GTK software by typing words on your keyboard, showing all entries that matched. It was a very efficient way to navigate software, more than moving the mouse and hunting for entries trying to find the right submenu.
Using Ubuntu when Ubuntu introduced Unity meant avoiding the worst time period of Linux desktops. It was also the era of KDE 4 which should have been named "SIGSEGV 4.0" a full featured desktop that showed constant segmentation fault dialogs.
Ubuntu didn't become popular for no reason. It was a really sad state of affair.
I don't like Ubuntu anymore. Since they dropped Unity they completely abandoned any contribution to the linux desktop as a whole, while snaps are flatpak but much worse (the more you install, the slower your boot, and apps launch much slower than on flatpak) and with a proprietary backend. I see it now as a me-too distro that does everything worse. But I have fond memories of it. Debian stable + flatpak + podman is giving me the experience I seek in a desktop these days : no fuss, the OS has all the packages I need, if I need something more recent I can use a pet container or flatpak, the polish is good enough (and, unfortunately, other distros don't really improve enough there to justify their existence), I don't have to /think/ about my system for the duration of the stable release, only when the time comes for the next full-upgrade, the modern installer sets up a sane desktop out of the box and now they even include firmware by default. It's the zen I need.
> I had the misfortune of having to maintain an 18'000 line bash 3 script
My hats off to you, I do not think I have the fortitude to stomach.. this.
> run it with busybox with the "exec prefers applets" option
> edit: it's actually the "run 'nofork' applets directly" option. Can give quite a speed boost compared to bash if you have to call "external" utilities like grep/head/etc.
Nifty trick, I had no idea about that, thanks for sharing this.
People all too often forget that there is often a lot of extra documentation hidden in /usr/share/doc/ when you install -doc packages, at least on deb systems, and not just info and manpages. For example, the bash manual you cite is in /usr/share/doc/bash/bashref.pdf along with its html version as bashref.html. There is also an /example/ folder filled with commented programs and functions to serve as reference. And a README that suggests looking for "Advanced Bash-Scripting Guide" which is a massive online book filled with all sorts of esoteric knowledge. You can also find things like the release changelogs and one that details incompatibilities from previous versions.
While there are exceptions, most packages have useful goodies in there to check first before one has to think about looking things up online.
It is nothing as major as what Python does, but there are routine paper cuts through deprecation and breaking changes across versions, the most notable being 1.9 and 3.0.
But the language itself isn't the worst offender, the whole ecosystem around it tends to not even make reasonable attempts at stable APIs. Which isn't helpful with the way dynamically typed languages typically lack in tooling to safely, properly deal with refactoring - there are exceptions like smalltalk I've heard, but overall the cavalier attitude toward delivering a constant treadmill isn't pleasant to me. Of course, some may argue that the reason Perl doesn't suffer as much from it is because it is "dead", but I'll take dead over busywork.
I must say, I don't like Java the language, but Java the platform almost feels like the promised land compared to this. I don't use it to develop myself, but when I ran into an old unmaintained jar and ran it on a current JVM and it just works.. it feels.. fantastic. Absolutely wonderful. The same sort of feeling I also have when I run old games on Wine and it just works. win32 is the stable API I always wished linux had for GUI apps but will never have because the culture is all about CADT.
I like to write posix sh scripts for the sake of portability and, funnily enough, future proofing as I don't like having to maintain stuff against changes that break compatibility, which is something bash does (archlinux is still on an older bash even though debian stable has the latest, because bash 5.2 broke some of archlinux's own scripts. This is why you should not write bash scripts.), but bash being slow isn't one of the good reasons. If your scripts do that much work that your shell's speed matters, you should reconsider writing shell scripts and start thinking about using something like perl, python or ruby. I'd suggest perl, if only because unlike the latter, perl doesn't constantly pull the rug under you and make you do busy work to make sure your scripts work on the latest runtimes.
Is the fastest way of becoming proficient with shell scripting. Whether it's pure posix shell, or bash and its extensions, they're small languages and can be learned in a week end if you're proficient in another programming language. The main pain point is that there's a lot of "surprises" and non-intuitive behaviors, that are all listed here. The first ones, about parameter expansions, quoting variables and leading dashes are the most common issue with newbies in shell scripting.
There's a lot of amazing tooling these days to make sure your shell scripts are fine too.
First, shellcheck:
And finally, checkbashisms if you intend on making pure posix scripts that are compatible with debian/ubuntu's dash. It is part of the debian's devscripts suite, but is often individually packaged in other distros.
> Also you can use the chat as a learning tool
Or you could learn from a guide written by people who have suffered decades of experience of the pitfalls of shell scripting and have shared their woes.
This isn't the first time, and won't be the last time, something like that happens with grub, and it's entirely an issue with the user not doing what they should when they run archlinux or some other minimalist distribution that doesn't automate the process of updating grub.
Grub uses a configuration file generator that reads from the human readable/editable /etc/default/grub and creates a /boot/grub/grub.cfg, and the result of that generator doesn't have a stable "interface". At any time, an update to grub might read grub.cfg incorrectly, if you do not generate it again.
99% of the linux distributions out there had no breakage with grub because they run the grub-mkconfig command every time grub is updated through grub-install. It is automated within the scripts included in the packaging of the distribution and the user will never see any of this in Debian, Ubuntu, Fedora etc. If a newer grub package comes out on those distro, the scripts will run both grub-install and grub-mkconfig. There will never be a mismatch between the grub binary versions and the config file state.
Arch Linux users who knew how grub works also had no issue. If you update grub, you must regenerate the config file (it's a "if you update" because arch linux, by default, will NOT automatically update grub at all, updating the package is not the same as updating grub). If you edit the config file and regenerate it when you have a newer grub package installed, you must also update the grub binaries. So any time you do something with grub, you MUST run grub-install, then grub-mkconfig. Doing only one of the two is akin to doing a partial upgrade, which is a no-no.
If, as I suspect, you're an arch user, I would recommend switching to systemd-boot, which doesn't even need a configuration file at all if you set up your system to follow its conventions and use unified kernel images. EFI binaries are automatically scanned and shown in the menu and it uses EFI variables to remember the few settings you can interactively edit, like the preferred kernel to boot. It's robust and only has what is needed in a small, KISS boot manager. It can't even be truly called a boot loader because that part is managed by efistub which is part of the unified kernel image. Very unlike grub, which has the whole kitchen sink, including its own implementation of a ton of filesystems..
This went to court and the man who sued for discrimination lost his case.
> -- A man whose bid to become a police officer was rejected after he scored too high on an intelligence test has lost an appeal in his federal lawsuit against the city.
> The 2nd U.S. Circuit Court of Appeals in New York upheld a lower court’s decision that the city did not discriminate against Robert Jordan because the same standards were applied to everyone who took the test.
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.