Installing / uninstalling / updating software should be a service provided by the OS. Letting vendors do it themselves just gives them an opportunity to mess it up, and they frequently do.
Windows provides various installer systems (.msi and the later iterations for UWP applications). It's unfortunate that MSI files aren't used more often, because they're more reliable than their uninstall.exe counterparts. They're not unlike .deb/.rpm files, except they integrate with the system GUI better when it comes to prompts and variables.
I believe MSI files were originally supposed to be almost atomic in use (software is either installed or uninstalled), providing transactional operations for installing software and limited UI options. I remember (but can't find) an old quote from someone on the team that designed the file format, basically saying something among the lines of "giving developers the option to execute random commands from MSI installers was the worst decision we've made".
I can't speak for whether Apple gets it right, but my experiences with the various package managers on Linux have not been any better than my experiences with installers on Windows. I've settled for avoiding system packages for anything I can build from source since system packages are always outdated and often Strange, and I try to avoid third party package sources and weird stuff like Snap or Flatpak since it's also historically been a source of problems for me. Maybe life is better outside of the Debian sphere though, since I've only dealt with Ubuntu and Debian.
I don't quite get this, I've been using Debian-esque Linux since like 1997 in various forms and have had problems with apt-get/apt maybe five times since then in total and it's always fixable with a little work. I've seen this a lot and I've haven't really understood the problems.
I saw Linus from LTT brick his installation (in Pop_OS! I think?) but that was a clear user error.
A user error that can happen to any user who isn't Linux savvy and just wants to paly games, and not learn how a package manager works, and that it can uninstall your desktop environment if you aren't proficient with Linux, is no user error but OS error.
How many MacOS or Windows users expect that going through the installation steps of Steam, it can uninstall your desktop environment? For that user demographic, that is a clear OS issue.
There was a Steam package error, the error warned it might be temporary, the installer said it wouldn't continue because that would remove "popos-desktop" amongst other things.
So, he opened a console (like any user?), then used apt-get ... which had a WARNING ... "This should NOT be done unless you know exactly what you are doing!". He then had to type "Yes, do as I say!" in order to "do something potentially harmful" ... and then, what a surprise it did something harmful!
That's a user error that will only happen to people who are cocky, people who are idiots, or people trying to firm up their long held stance that 'Linux isn't for gaming'.
I saw the LTT video the following day to release, loaded a VM up, installed Pop_OS (my first time) and installed Steam, no issues. Very simple. All button clicking.
>going through the installation steps of Steam //
That's mis-characterisation, he went through the Steam install steps (click install by the Steam icon), the OS told him there was an error and refused to do it. End.
Then he went sudo-ing and ignoring warnings. "You can delete System32 this OS isn't ready for users!".
You'll tell me now installs never fail on Windows, presumably, despite having experienced them myself.
That would happen to any other user trying linux for the first time because not every user knows they should first update their packages before trying to install something because why doesn't the OS do it automatically like any other OS?
It's 100% an OS UX error you're trying to spin into an user error.
The problem isn't "apt" so much as "the system apt packages do weird things and as a result I can't build this open source package" or "I updated Ubuntu and now varnish and znc don't work even though I was using the system packages" or "the system apt package for mono is just plain broken and it conflicts with one I build from source, so I have to uninstall it"
mundane gripe: Uninstalling an apt package is too complicated and it is beyond me why it isn't a single command in 2023. I have to skim stackoverflow answers every time I need to do it (multiple times a year).
YMMV. I just bricked a Debian install last month by using the package manager to install display drivers then trying to uninstall it to try a different driver. Had to go editing files in the console on a 4k display and just cross my fingers.
I think part of it is that Debian and Ubuntu try to ship a good, usable default config, which is not necessarily the upstream default. I think it makes it hard to debug config issues.
This makes me think of the recent changes to pip on Arch Linux that recommend installing modules with pacman.
Pacman is ok, but I recently destroyed the Ruby installation on a computer while trying to use Vagrant and other Ruby packages. I still haven't figured out how to fix it. Lesson learned, stick to AUR and pacman repo.
Virtualenvs are your friend. I use pipx for Python utils not in my OS repos, never had a problem with that. (`pipx install yt-dlp` creates a venv in ~/.local/pipx/venvs, installs yt-dlp there, then symlinks the executables to ~/.local/bin.)
For per-project dependencies, Poetry is pretty good, although there are other options too.
For Ruby, I think Bundler is the venv/Poetry counterpart. Not sure what you could use for installing global tools though.
I was thinking the amount of whataboutism has a familiar smell. Just accept you live in the ass-end of the world where few want to (and even then it seems we want to kick out those who would), and that it comes with a price tag.
> I feel like this anti car sentiment comes from people who already don't have access to a car and have already molded their lives around public transportation and of course then it is easy to say we should get rid of cars.
Let's start with this, it's kind of obvious. "Cars are evil but I have two" would likely cause severe cognitive dissonance. Choosing to live carless is going to shape your life. It restricts where you can live, what jobs you can accept, your hobbies, family planning etc.
> What if I need a car for commuting?
Then you get a car for commuting, if you have to haul a lot of gear, can't move closer to your work, or choose another work that's accessible without a car.
> Is it really reasonable to ask me to start using public transportation and completely revolve my life around a their schedule?
Ideally you'd get public transit that runs often enough that you don't bother checking the schedule before heading for the stop, it'll be a couple of minutes of wait at worst. If you need to go somewhere off hours you accept the longer wait or the occasional taxi fare as a cost of not owning a car. That will rule out living anywhere that doesn't have the population density to support it, or is otherwise too car-centric.
> Meaning that if I don't pay extra to nab one of the spaces (+ maintenance fees and whatnot) there wouldn't be a place for my car
If there's no parking lot expanse, parking needs to be placed underground or within buildings, unless a lot more people are willing to go carless. It's going to be expensive, and someone has to pay for it. As long as it's not you, right?
> there would only be tiny expensive grocery store as my only walkable shopping place
This sucks. It's the kind of place you'd immediately rule out if you don't have a car. This is partly poor city planning, and partly a chicken-and-egg problem. Zoning for those apartments should take into account that there is enough space reserved for services within a walking distance. But if everyone just takes a car to the nearest highway hypermarket, there's no point for anyone to bring the services closer. Btw. we get our groceries delivered weekly since covid, I'm not looking to go back to a supermarket that's intentionally designed to waste my time walking past every single product to get what I need.
Disclaimer: not a "fuck cars" extremist, I just don't like driving very much, cars are expensive to own and operate where I live, a hassle to own and maintain in general, and inconvenient as a mobility solution in my immediate surroundings. So I've decided to try to hold out as long as I can (~20 years of adult life so far).
For something that's going to annoy you daily for the next 10+ years? I'd definitely pay $10. I'd pay another $10 for the dishwasher to remember the program selection instead of always offering the 4+ hours eco program (which I believe is required by some regulation to be the default).
I already paid $100 more for 2dB less, according to the spec. No regrets.
I'd say it depends on how long it takes to boot up. Fortunately, my dishwasher boots up instantly. If it takes a few seconds, sure it's annoying, but you can work around that. Say press the on button, then check the detergent is in place, etc, then press start. If it's some ridiculous length, like several minutes, I'd probably only buy that crap at a steep discount.
> which I believe is required by some regulation to be the default
Huh. This must be recent-ish. My parents' dishwasher has a rotary button to choose the program, which stays put as long as the little grandchildren don't mess with it..
> From 1 March 2021, household dishwashers shall provide an eco programme meeting the following requirements:
> (a) this programme shall be: [...] set as the default programme for household dishwashers equipped with automatic programme selection or any function maintaining the selection of a programme, or, if there is no automatic programme selection, available for direct selection without the need for any other selection such as a specific temperature or load;
Ours was bought in late 2020, but manufacturers probably take a head start with implementation whenever they renew their models.
It seems that the only part that got implemented out of that draft was drowsiness/inattention detection. At least that's what I read from the document in "Commission adoption" section of that page.
I think it's fair to point out that the buses with cargo space are mostly used for long distance routes. Local traffic buses used by most cities don't have dedicated space for luggage.
another bug report:
in chat, after somebody changes their nickname and you try to use tab completion on their name, it will use the original nickname for completion
I mean you have to be able to do history manipulation if you want to have history to any meaningful changes you do via JS on a page (and you should make sure to adjust the URL as well so people can go back to that information).
But I agree, it should not be possible to prevent users from leaving back from the site.
You can easily spam the browser history using a redirect slide, effectively preventing users from leaving the page. No need for any JS, works even with active ad blockers. It’s relatively common on malicious sites.
Many media do this these days, it's become an industry standard.
And to be fair I do get the point why they are doing that, good journalism has to be financed somehow lest you end up with a situation like in Austria where corruption scandals involving government-paid ads wrecking the entire political establishment and media elites of the country [1].
> magic framework stuff that Laravel/Symphony provide
The magic in these frameworks is evil, and likely a big part in ruining PHP's reputation. Laravel in particular hides way too much stuff behind magic, and when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
This is one of the reasons I like PHP, in newer PHP versions it is an attribute but in older versions it is just a comment. Clever and backwards compatible.
It isn't backwards compatible (`#[foo` used to be legal PHP 7, but is illegal in PHP 8).
It may technically be forwards compatible syntactically (`#[foo]` will, as you say, just be ignored by PHP 7), but that's an anti-feature (assuming that the attribute isn't a no-op, it'll presumably break something else).
And a program can generally read its source code and make fancy adhoc interpretation, sure. That’s nowhere close to specified facilities that you are guarantied to be able to use with a fair amount of trust in the resulting outcome with the regular toolbox.
I honestly prefer community supported battle proven production ready "magic" than what most product developer under a deadline cobble together. In my experience the problem you describe happened like... 2 times in my 20 years career. And I literally spend my entire days fighting my own colleagues very explicit smartnesses
One is that the framework can do all the magic under the wood, or not, and in (almost) no case leak any clue about that.
Or, the framework can provide a lot of facilitation through conventions and there no real benefit to use this framework if you don’t leverage on these facilities. Having conventions doesn’t mean you have to be acculturated to all of them upfront though, as with proper modern IDE the learning curve can be very smooth and funny.
> when it goes wrong you find yourself sifting through OOP-obfuscated layers of framework and libraries just to find out how exactly your controller is called.
debug_backtrace() has always been my friend in situations like this
What ruined PHP's reputation is people believing the language itself was a sufficient framework and unsafe SQL and escaping practices being the norm, due to naive developers (which PHP has plenty of) thinking the simplest solution (eg concatenating strings and variables into SQL queries vs prepared statements) is always the most correct.
I mean, with PHP you either use a framework or you necessarily end up writing your own ad-hoc, informally specified, bug ridden implementation of one. At least frameworks like Laravel are battle-tested and should at minimum cover the most obvious issues.
I agree with you. But, and this is a big but, it's a tradeoff. You also get benefits.
This is why I said "buy-in". If you are comfortable with doing things in their way, you get a ton of leverage: easily consistent code, a fast and productive "get off the ground" experience. The downside is what you described.
Personally I'm just not a fan anymore of these things. You quickly produce code that _looks_ clean and consistent. But it's also bloated and brittle, especially if you need to break out of the happy path. A framework like that is great if you don't do software design, but more of a hindrance if you do. There's no framework that can help you do a holistic solution. For that you need good tooling, a robust foundation (AKA not PHP and probably not JS) and a simple design.
Again: Trade off.
That's why many here in these discussions will tell you that X or Y is the best thing since sliced bread - because it fits their needs almost perfectly. But you also get many (like us) who have at least some reservations, because had to bend over backwards to fit a square peg into a round hole and ultimately wasted so much time that using X or Y wasn't worth it at all.
It's like that with every framework: Laravel, Rails, Django, you name it.
If you build a class of thing which the framework creators had in mind, and do not have a need to deviate from the prescribed ways, it's a force multiplier.
Once you try to build something that does not fit the confines of the framework, it's of course possible, but the framework stops helping you, and after some time becomes more of an impediment instead.
"...Once you try to build something that does not fit the confines of the framework..."
Can you provide an example of that? In my experience people think too quikcly they're smarter than the community behind the framework and that it doesn't fit their use case, and the real cause is just that they don't "like" the recommendations and think they can do better. Plot twist: They don't, and usually end up creating a terrible mess. What would be the alternative? Building your own in-house undocumented, untested, unproven framework and/or tying together 100s of libraries? Are you convinced that's going to lead to a better result for all use cases of your application? And that once you leave the company, the next developer will think "Oh, this custom framework is great... I'm glad they didn't use Rails/Django/Laravel"... not my experience... at all.
I think that these frameworks are the best choice for most project, and if they're not (Like.. you're building Google Earth or Figma or something really different) then the problem is that you picked the wrong tool from the get go.
I don't think that "this one special case" is special enough like to not use a batteries included framework and go wild with your imagination. Unless you're a FAANG, otherwise you're wasting your employers money.
As an anecdote, I once worked for a shop that used Django. One of the developers before I was there "decided" the Django ORM was bad and promoted bad practices, etc, etc... so he wrote his own "better" ORM on top of a postgresql library. You can imagine how that went, specially after he left and the second gen of devs arrived to deal with the monstrosity.
This happens a lot more frequently than you think.
We should stop thinking we're "so special". We must focus more on providing business value by writing product code, tests and documentation and less rewriting the world because it's cool.
I've been building on Laravel for some years now and I'm always delighted how you can just ctrl+click and see the internals (and the magic). They're pretty modular and extensible/overridable.
