0 users browsing Discussion. | 3 guests | 5 bots  
Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
Pages: First Previous 1 2 3 4 5 6 Next Last
Posted on 19-07-07, 12:42
Full mod

Post: #294 of 394
Since: 10-30-18

Last post: 31 days
Last view: 4 hours
I agree that it's redundant to have an OS-provided hierarchy at / and another one at /usr, especially since the "minimal boot environment" is initrd these days, instead of a root partition. However, I also expected the resolution to be "move stuff out of /usr" rather than "move stuff into it". After digging around for a bit, and ignoring stupid reasons like "because Solaris did it", I actually uncovered what I think is a half-decent reason for doing it this way around.

The "traditional" Unix root file system has a bunch of directories for OS-provided stuff (/bin, /lib, /usr, /sbin), and a bunch of directories for machine-local stuff (/etc, /home, /var, /tmp). If you want to do something like "take a snapshot of the OS installed files" it's a bit of a hassle to keep the OS-provided and machine-local stuff separate. If you're using a FS that can atomically snapshot a directory (like btrfs or ZFS), it's actually impossible to do that correctly.

The "new" Unix root filesystem has exactly one directory for OS-provided stuff, /usr. Everything else is machine-local (or a standard compatibility symlink). That makes it a lot easier to keep Os-provided and machine-local files separate.

Of course, there's still legacy quirks, like /usr/local actually being machine-local instead of OS-provided, but maybe that can be a symlink to /opt or something.

Or maybe we should burn it all to the ground and switch to a distro that tries to solve the problem Once And For All, like NixOS does.

The ending of the words is ALMSIVI.
Posted on 19-07-07, 15:45
Stirrer of Shit
Post: #470 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
I thought something like stali'd be cool:
Filesystem

/ - the root home
/bin - all executables
/sbin -> /bin # softlink pointing to /bin
/boot - all boot files
/etc - system configuration
/home - user directories
/var - spool, run, log, cache
/share - man pages, locales, dependencies
/include - include/headers
/lib - static libraries for building stuff
/mnt - mount points
/usr -> / # softlink pointing to /

Based on the Linux assumption:

/dev - devices
/proc - proc files
/sys - sys files

For crap stuff:

/sucks - stuff that sucks, like ugly gnu library dependencies, or systemd fake handlers

If we're discussing cool filesystem hierarchies, why not GoboLinux? Imagine that with static linking and each program in its own jail. Would be super cool.
(Of course, they should drop the Windows-esque capitalization, but you can't have it all)

While we're at it, /var/log should be mounted as tmpfs, there should be an option like noatime for ctime and mtime, there should be an option to clamp timestamps (e.g. anything older than X days gets rounded to Jan 1, 1970), or to use a monotonic but otherwise random clock. Furthermore, applications shouldn't get to write files willy-nilly without my consent. In particular, none of the damn log files that I did not request or know about. GTK (?) is the worst offender, requiring this ugly hack to respect my privacy:
chmod 000 ~/.local/share/recently-used.xbel
chmod 000 ~/.local/share/gvfs-metadata
chown 000 ~/.xsession-errors
chmod root:root ~/.xsession-errors
chown root:root ~/.local/share/gvfs-metadata
chown root:root ~/.local/share/recently-used.xbel
sudo chattr +i ~/.local/share/recently-used.xbel
sudo chattr +i ~/.local/share/gvfs-metadata
sudo chattr +i ~/.xession-errors



Maybe each package could have "permissions," like on Android. So something like GIMP wouldn't ever have the "state" permission, and all files (except for those created through the save file dialog) would be written to a temporary overlay filesystem that goes away when you close GIMP.

/pipedream

Could something like "take a snapshot of the OS installed files" realistically be accomplished? For instance, Debian's torbrowser-launcher puts its binaries in ~/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/, while Firefox lives in /usr/lib/firefox-esr/. Wouldn't everything break if you removed /etc, for instance?

It's probably far more suitable to force people into gradually upgrading approaching the local maximum than it is to have them do a giant leap and hope they don't resist. If competently implemented, the end goal is the same.

I mean, compare the success of the early 2000's DRM schemes (CPPM and friends) to the success of the current ones. Boiling frog and all. In ten years piracy won't even be possible.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-07, 19:28
Custom title here

Post: #552 of 866
Since: 10-30-18

Last post: 2 days
Last view: 16 hours
Posted by Screwtape

Or maybe we should burn it all to the ground and switch to a distro that tries to solve the problem Once And For All, like Windows does.


Fixed it!

--- In UTF-16, where available. ---
Posted on 19-07-07, 21:46
Not from my cellphone

Post: #426 of 664
Since: 10-30-18

Last post: 4 days
Last view: 5 hours
Or we should abandon computers for good.

I want an OS that stashes all binaries in /DANGERMINES, but I guess that I can't have that, hence computers are doomed.

Licensed Pirate® since 2006, 100% Buttcoin™-free
Posted on 19-07-07, 23:25
Stirrer of Shit
Post: #472 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
Posted by CaptainJistuce
Posted by Screwtape

Or maybe we should burn it all to the ground and switch to a distro that tries to solve the problem Once And For All, like Windows does.


Fixed it!

Windows does actually have a sensible approach to software. Each program gets its own directory and contains whatever DLL files it needs. Sure, there are some kludges (AppData, registry), but those are present on Linux too.

In an ideal world, each file created by a program would be "tagged", so that the removal of the program would guarantee the removal of all the files it created (except those the user took ownership of, obviously), but since we do not happen to live there we unfortunately have to put up with installers/package managers, both of which are flaky and unpleasant.

Ultimately, I think we should just throw out the whole package manager thing. Each package gets distributed as an AppImage, but stripped of its dependencies which are replaced with their hashes. Then, upon execution, they get lazy-loaded, either from cache or from the Internet, and added to the AppImage. Then the filesystem handles deduplication. Maybe the last step could be skipped by just not adding them to the AppImage.

This means
1) packages are as small as before
2) packages have no dependencies, just latency
3) cached packages can be deleted at random and have no integrity requirements, being just SHA256-identified blobs
(although doing this without an Internet connection might break stuff)
4) there is no need for a central server, as BitTorrent can be used
(although you would like one since it'd be a shame to not have enough seeders for Firefox)
5) since packages are aware of all their dependencies, sandboxing becomes trivial
6) packages can declare upfront what privileges to request from the sandbox, like mobile apps

You might say that this is just re-inventing package managers, but consider that the complexity is far smaller. For starters, no dependency trees. Perhaps more importantly: unused applications' dependencies can be trivially pruned, without having to reason about whether they might be used at one point in the future. Or conversely, the size of dependencies can be held constant, although this produces non-deterministic behavior without Internet access.

I think this could be possible if you went with a hybrid system: XFCE and such get installed with the usual package manager, but applications without such deep tendrils (think Firefox, and most other software on your system) get the AppImage treatment.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-08, 00:06
Custom title here

Post: #554 of 866
Since: 10-30-18

Last post: 2 days
Last view: 16 hours
"Windows does actually have a sensible approach to software. Each program gets its own directory and contains whatever DLL files it needs."
That's... not actually true.

--- In UTF-16, where available. ---
Posted on 19-07-08, 00:32
Stirrer of Shit
Post: #474 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
Well, sure, there are some kludges, but in essence that's how it works, isn't it? Each program has some .dll files shipped with it and it has a folder in the Program Files/ hierarchy. I can't ever remember Firefox or whatever hassling me about dependencies on Windows, except for .NET and friends, but those are practically part of the system anyway.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-08, 00:54

Post: #99 of 158
Since: 10-30-18

Last post: 2 days
Last view: 1 day
Posted by CaptainJistuce
"Windows does actually have a sensible approach to software. Each program gets its own directory and contains whatever DLL files it needs."
That's... not actually true.

Yeah, he's definitely never done any Win32 programming, let alone with a free compiler.
Posted on 19-07-08, 02:04
Stirrer of Shit
Post: #475 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
Hardly anyone except for people porting Linux software uses MinGW/Cygwin, do they? When in Rome, do as the Romans do...

I can't remember once having had to reason about the dependencies of an application, or have an application require 200 MB of mystery meat libraries with scary-sounding names to run.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-08, 03:14

Post: #100 of 158
Since: 10-30-18

Last post: 2 days
Last view: 1 day
Posted by sureanem
Hardly anyone except for people porting Linux software uses MinGW/Cygwin, do they? When in Rome, do as the Romans do...

Visual studio wasn’t free until recently. The free version until a couple years ago was also non-optimizing. Before that we had RSXNT, LCC, then Cygwin and Mingw. VC6 was several hundred USD at the minimum, and VC7+ only came with the more expensive Visual Studio, so nothing else was available for the aspiring young programmer.
Posted on 19-07-08, 05:09 (revision 1)
Custom title here

Post: #555 of 866
Since: 10-30-18

Last post: 2 days
Last view: 16 hours
" Well, sure, there are some kludges, but in essence that's how it works, isn't it? Each program has some .dll files shipped with it and it has a folder in the Program Files/ hierarchy."


That's the kludge to avoid an express trip to DLL Hell. Shared libraries used to be the standard. They also broke the hell out of everything because different versions of the same libraries were incompatible due to the DLL format. Windows 98 finally put this issue (mostly) to rest with SxS, which allows the OS to host multiple versions of the same DLL and serve different ones to different programs running at the same time(and now you know what WinSxS is when you stumble across it in your system)

That said, you don't SEE the dynamically-linked libraries the program DOESN'T carry in its install directory, which is decidedly non-zero.



"I can't ever remember Firefox or whatever hassling me about dependencies on Windows, except for .NET and friends, but those are practically part of the system anyway. "

So... common libraries don't count as libraries?

And the installer will get most of the libraries it needs to install installed silently. It is only the collections with separate installers(DirectX, Dot Net) that you ever see. And, well, that's most of the responsibility of an installer. They aren't just a self-extracting ZIP file. (Similarly, that's why you've long been encouraged to use the uninstaller instead of just deleting the directory, it lets the system know the program is no longer using those DLLs and gives it the option of deleting them if no one uses them)


" I can't remember once having had to reason about the dependencies of an application, or have an application require 200 MB of mystery meat libraries with scary-sounding names to run. "

When is the last time an installer actually told you what it was doing in any detail?



Certainly, the more robust Lunix package management system leads itself to elaborately tangled webs of dependencies, whereby installing a Super Nintendo emulator will bring in printer support as a dependency(because of some of the fonts used, if I recall), or byuu's old goto example of a graphical front-end for command-line CD burner software changing his init system.
But that doesn't mean the Windows situation is actually any better, or that Windows has no dependency situations. They just trade depth for width in Redmond's hole.

--- In UTF-16, where available. ---
Posted on 19-07-08, 06:24

Post: #164 of 266
Since: 10-29-18

Last post: 1 day
Last view: 2 hours
Posted by sureanem
4) there is no need for a central server, as BitTorrent can be used

Torrents can't be easily deleted, which makes them less attractive for the creators.

My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Posted on 19-07-08, 08:00
Full mod

Post: #296 of 394
Since: 10-30-18

Last post: 31 days
Last view: 4 hours
Posted by sureanem

Ultimately, I think we should just throw out the whole package manager thing. Each package gets distributed as an AppImage, but stripped of its dependencies which are replaced with their hashes. Then, upon execution, they get lazy-loaded, either from cache or from the Internet, and added to the AppImage. Then the filesystem handles deduplication. Maybe the last step could be skipped by just not adding them to the AppImage.

I've always had a soft spot for the way NeXTStep applications work (and hence early macOS applications, although I don't know if these features have been deprecated in newer OSs): each application includes all the libraries it depends on, BUT it includes them with a standard naming scheme. When the OS sees an application for the first time, it scans the libraries it provides, and adds them to a system-wide database. When an application is launched, the OS scans the database to find the latest version of each library the application needs. So a user might download and install your application that includes Foo.framework version 1.3, but some other application already provides Foo.framework version 1.5, so when your application starts up, it uses version 1.5 from the other app. If the other app is uninstalled at some point in the future, your app goes back to using its bundled version 1.3.

This is a super-cool and amazing system compared to, say, Windows NT 3.5 or whatever Unix systems were doing at the time. In the modern age, it's a bit scary - what if somebody manages to sneak Malware.framework onto your system, renamed to Foo.framework? What if a particular version of a framework is broken, but it's a higher version so it gets chosen every time? How would you debug a problem like "three of my applications crash, but only when this other application is not installed"?

The ending of the words is ALMSIVI.
Posted on 19-07-08, 11:08
Post: #228 of 353
Since: 10-30-18

Last post: 1 day
Last view: 1 hour
Posted by sureanem
Well, sure, there are some kludges, but in essence that's how it works, isn't it? Each program has some .dll files shipped with it and it has a folder in the Program Files/ hierarchy. I can't ever remember Firefox or whatever hassling me about dependencies on Windows, except for .NET and friends, but those are practically part of the system anyway.
Most programs will install the dependencies during program installation.

AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64
Posted on 19-07-08, 12:15
Stirrer of Shit
Post: #476 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
Posted by BearOso
Visual studio wasn’t free until recently. The free version until a couple years ago was also non-optimizing. Before that we had RSXNT, LCC, then Cygwin and Mingw. VC6 was several hundred USD at the minimum, and VC7+ only came with the more expensive Visual Studio, so nothing else was available for the aspiring young programmer.

Is that really a real-world concern? Windows isn't free either, but it's not common to pay for it (save for OEM).

Posted by CaptainJistuce
That's the kludge to avoid an express trip to DLL Hell. Shared libraries used to be the standard. They also broke the hell out of everything because different versions of the same libraries were incompatible due to the DLL format. Windows 98 finally put this issue (mostly) to rest with SxS, which allows the OS to host multiple versions of the same DLL and serve different ones to different programs running at the same time(and now you know what WinSxS is when you stumble across it in your system)

I don't see it as a kludge, it's a beautifully clean solution. No dependencies, no problem.

That said, you don't SEE the dynamically-linked libraries the program DOESN'T carry in its install directory, which is decidedly non-zero.

That's true. But they can't be that big, can they?

So... common libraries don't count as libraries?

Sufficiently common ones don't. If an application depends on glibc, well that's like saying it "depends" on you having a CPU inside the computer, isn't it? glibc is a part of the OS, just like .NET. Why they don't ship it with I don't know. On a long enough timeline, all Windows installs end up with .NET installed.

Posted by Nicholas Steel
Most programs will install the dependencies during program installation.

And the installer will get most of the libraries it needs to install installed silently. It is only the collections with separate installers(DirectX, Dot Net) that you ever see. And, well, that's most of the responsibility of an installer. They aren't just a self-extracting ZIP file. (Similarly, that's why you've long been encouraged to use the uninstaller instead of just deleting the directory, it lets the system know the program is no longer using those DLLs and gives it the option of deleting them if no one uses them)

...

When is the last time an installer actually told you what it was doing in any detail?

Touché.
Still. You would notice if the installer was several hundred megs. It's very rare for installers to download things over the internet. And you can notice it's rare for installers to be that big.

Certainly, the more robust Lunix package management system leads itself to elaborately tangled webs of dependencies, whereby installing a Super Nintendo emulator will bring in printer support as a dependency(because of some of the fonts used, if I recall), or byuu's old goto example of a graphical front-end for command-line CD burner software changing his init system.
But that doesn't mean the Windows situation is actually any better, or that Windows has no dependency situations. They just trade depth for width in Redmond's hole.

Well, they could make a better trade. I agree it's a trade-off, though.
Posted by Screwtape
Posted by sureanem

Ultimately, I think we should just throw out the whole package manager thing. Each package gets distributed as an AppImage, but stripped of its dependencies which are replaced with their hashes. Then, upon execution, they get lazy-loaded, either from cache or from the Internet, and added to the AppImage. Then the filesystem handles deduplication. Maybe the last step could be skipped by just not adding them to the AppImage.

I've always had a soft spot for the way NeXTStep applications work (and hence early macOS applications, although I don't know if these features have been deprecated in newer OSs): each application includes all the libraries it depends on, BUT it includes them with a standard naming scheme. When the OS sees an application for the first time, it scans the libraries it provides, and adds them to a system-wide database. When an application is launched, the OS scans the database to find the latest version of each library the application needs. So a user might download and install your application that includes Foo.framework version 1.3, but some other application already provides Foo.framework version 1.5, so when your application starts up, it uses version 1.5 from the other app. If the other app is uninstalled at some point in the future, your app goes back to using its bundled version 1.3.

This is a super-cool and amazing system compared to, say, Windows NT 3.5 or whatever Unix systems were doing at the time. In the modern age, it's a bit scary - what if somebody manages to sneak Malware.framework onto your system, renamed to Foo.framework? What if a particular version of a framework is broken, but it's a higher version so it gets chosen every time? How would you debug a problem like "three of my applications crash, but only when this other application is not installed"?

Well, you just refer to it through the package repo's name for it or by hash, problem solved.
My suggestion is very similar, just that it wouldn't include the libraries, just their hashes, and then the OS downloads them from the repos. If it's running low on disk space, it can delete big libraries at random without much happening.
Posted by creaothceann
Torrents can't be easily deleted, which makes them less attractive for the creators.

When do you want to delete glibc though? The program itself would still be distributed like normal.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-08, 12:52
Praise Celestia!

Post: #292 of 480
Since: 10-29-18

Last post: 2 days
Last view: 25 min.
User is online
Posted by CaptainJistuce
When is the last time an installer actually told you what it was doing in any detail?
I can't be specific enough to name names but roughly half-ish of all applications that used NSIS installers were more than willing to go into detail.
Posted on 19-07-08, 13:16
Not from my cellphone

Post: #427 of 664
Since: 10-30-18

Last post: 4 days
Last view: 5 hours
Posted by Kawa
Posted by CaptainJistuce
When is the last time an installer actually told you what it was doing in any detail?
I can't be specific enough to name names but roughly half-ish of all applications that used NSIS installers were more than willing to go into detail.

Then there are the old Wise installlers whose uninstaller logs were in plain, human-readable text, a play-by-play action of each action performed. You could even pick which actions to undo when uninstalling something: handy when getting rid of some shareware but without tampering with some OCX which by chance might be used by something else you could actually care (and for which whoever wrote the installer script forgot to flag it as a shared file): you could deselect unregistration/delete for said .OCX and get rid of everything else.

I've yet to see another uninstaller with such a fine-grained control.

Licensed Pirate® since 2006, 100% Buttcoin™-free
Posted on 19-07-08, 16:54

Post: #101 of 158
Since: 10-30-18

Last post: 2 days
Last view: 1 day
Posted by sureanem

Is that really a real-world concern? Windows isn't free either, but it's not common to pay for it (save for OEM).

Ah. The naivety of being born after dialup.
Posted on 19-07-08, 17:26
Stirrer of Shit
Post: #480 of 717
Since: 01-26-19

Last post: 74 days
Last view: 72 days
Posted by BearOso
Ah. The naivety of being born after dialup.
We're not living in the 90's anymore, gramps.

There was a certain photograph about which you had a hallucination. You believed that you had actually held it in your hands. It was a photograph something like this.
Posted on 19-07-08, 17:56

Post: #102 of 158
Since: 10-30-18

Last post: 2 days
Last view: 1 day
I was explaining the proliferation of free Windows compilers, which you don’t seem to understand. It isn’t because of the desire for cross-compilation. Since you’re pretending to ignore information, I assume you understand now, but just want to argue.
Pages: First Previous 1 2 3 4 5 6 Next Last
Main » Discussion » (Mis)adventures on Debian ((old)stable|testing|aghmyballs)
[Your ad here? Why not!]