161–170 of 310 posts
As for merged /usr, recently using Arch Linux for desktop use. Which accomplishes this by symlinking, which is ugly. Arch certainly is not perfect. Not sure if this is the way.
We can now kiss-gone the security for embedded world and its IoT-related security brethren. It is often the directory separation of /bin and /usr/bin that is used to denote the extent of firmware’s scope between these binaries that are require for a boot up and what are they require to support their applications. (Thanks, PDP-11). Such wonderful boundaries of IoT upgrade scope can and is often denoted as two-stage up…
From the reliability perspective (protecting against accidental damage), the /usr merge makes it easier to set up A/B booting and protect the entire system, rather than blessing a small subset of the system and preventing anyone from upgrading those components at all in the future.
Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…
I'd argue you are overstretching one example of one broken system to a whole class of systems. We can reframe these big egos as people who do not believe in democracy, but great believers in feudalism. (Though I do not know all the details what is going on in Debian, may be I misunderstand the affair, and I don't want to mark some specific people as anti-democrats, but I don't know how to aviod it, sorry).
We see how individual developers say "get off my lawn". The social dynamics of a collective decision making doesn't mean for them a thing. Any democracy needs a legitimate way to reach consensus. And everyone needs to conform to a consensus. Legitimacy of procedures must be enough for everyone to believe in the consensus or at least to believe in their obligation to conform. And the more power someone have, the more his obligations to conform are.
I mean, if I'm a regular voter without any special powers to resist consensus, then I cannot brake the consensus, I cannot stop system from working without resorting to really destructive and antisocial behavior. But if I was a president, I would have power, I could resist. But if I did then it would be not a democracy but an autocracy. If I was something in between a voter and a president, then the situation would be something in between, though probably the president may interfere with my plans, use their powers to stop me ruining the system.
In Debian it seems every developer maintaining something important enough have powers to resist any consensus reached. And moreover there are some who actually use their power to resist. And the system as a whole doesn't treat such behavior as them undermining the system and may be undermining the very idea of democracy. I'd say that Debian is playing democracy but didn't invested enough into building a mythology of a democracy, into making people believe in a divine right of democratic procedures to rule them all.
Though from other hand, it may be not a bug, but a feature of a system, because it pays to people by handling them some power, I believe it helps them to not burn out too fast. It charges the community with struggles and a constant fight, it provokes people-centered procedures, not rule-centered.
Current state of the UNIX file hierarchy is a mess. Many incarnations of GNU/Linux systems didn't contribute to a more elegant yet simplified directory structure. Just pick the one you like the most and serves the purpose of your desires. As for merged /usr, recently using Arch Linux for desktop use. Works decent enough to getting things done.
Everything important is usually at most 3 levels deep and the short names are very convenient (versus "C:\Users\xxx\Documents and Settings").
Compare to things like Windows: c:\windows\system32 that has 64 bit stuff in it, the whole c:\windows\syswow64 b.s., c:\Program Files (x86) and c:\Program Files, the hierarchy in the Windows registry which has "Windows", "Windows NT", "Microsoft Windows" (probably), etc.
Earlier quoted context omitted.
I don't compare you with a nazi, but you should understand that minority's can take over a country, that's what the nazis did but also the communists in romanov-russia...china is more complicated. It's something completely different, but maybe "nazi" is a red flag for you in comments...because not comfy. EDIT: And more actual, the Taliban's in Afghanistan, an absolute minority but the one with weapons, training, conn…
Or the Alawites in Syria, or the Europeans in 18th century North America, or the Mongols, or a hundred other examples. There's a line somewhere between less-violent "minorities taking over a country" and more violent Mongol-like "taking over", but I would say that the situation of a minority group seizing power is not significantly less common than of a majority group seizing power.
I understand the problem dpkg is facing (can't know the canonical pathname for an object is, in some cases), but I have huge problems understanding why a symlink farm is preferable. The last thing I want to see on my Debian system is directories with hundreds or maybe thousands of symlink entries. There must be a way to let dpkg do its job if the directory-symlink approach is used instead, surely? (/bin -> /usr/bin)
Earlier quoted context omitted.
There a lot of different biases in the world of tech, sightedness is just one of them. Are there any operating systems written from or computers built from a blind perspective, or are the blind just using the accessibility features of sighted operating systems?
> Are there any operating systems written from or computers built from a blind perspective Yes, but they struggle to keep up with the mainstream, especially considering the runaway complexity of the web. The one notable open-source example is Emacspeak [1]. The rest, as far as I know, have been proprietary and often overpriced products. [1]: http://emacspeak.sourceforge.net/
Just want to encourage you to keep pointing to accessibility problems loud and clear. While CSS complexity was mostly driven by ads, ecommerce, and porn, there are people who tried hard to do the right thing on the web (Paciello Group, W3C's WCAG, etc.), thereby also contributing to unwarranted complexity, who could benefit from feedback. And I don't have to tell you, but if you think you're not affected because you're young, sight/focussing problems kick in at about the age of 50.
Earlier quoted context omitted.
If you define majority as 50%+1, and minority as 50%-1, almost all democracies in the world have the minority in the power (unless they get 100% turn out rate with all votes contributing to parliamentary seats). Winning 60% of votes with a turn out of 70% voters is only 42% of the population.
Nah, people staying home on polling day doesn't stop them from being part of the majority opinion. If an option gets 60% of the vote, and there are no shenanigans going on, then that option is almost certainly the choice of the majority.
Does this also hold if the vote went 51% to 49% (in dual party system)?
Democracy is there to allow us to express a preference. Not voting is exactly that, a preference to not vote, and reasons are certainly various (including the one you mention of supporting the likely winner).
I understand the problem dpkg is facing (can't know the canonical pathname for an object is, in some cases), but I have huge problems understanding why a symlink farm is preferable. The last thing I want to see on my Debian system is directories with hundreds or maybe thousands of symlink entries. There must be a way to let dpkg do its job if the directory-symlink approach is used instead, surely? (/bin -> /usr/bin)
If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.
$ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?(I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier)
[1] http://www.drregex.com/2019/02/variable-length-lookbehinds-a...
Alternatively, a simple
grep --binary-files=text -rP '(?