EasyOS: An experimental Linux distribution

Cmon, we're not in 2005 anymore. Linux Desktop is fine for almost everyone even casual user with all big distros.

This GUI is as discoverable as a command-line tool which defaults to a help message

I could never remember all that and I would always have to refer to documentation to know how to write out the full commands.

On the other hand, I can download an ISO for almost any popular Linux distro and easily install it without reading a single word of documentation, even if I've never used that distro before.

ISOs make little sense over a regular disk or filesystem image for just about every use case except burning to optical media ...

Uh what!? About every single Linux distro has .iso files available.

And it typically makes way more sense to dump the .iso to a USB stick than to an optical media because it speeds up the installation big times. That's the case for Ubuntu for example.

And an example as to why optical media are kinda falling into irrelevancy: some distro like Ubuntu ship an ISO that doesn't even fit on a DVD anymore. It is an ISO meant to be dumped to a USB stick, not an optical media.

Now of course the downsize is that there is something very nice when you burn an .iso to a write-once optical media: once you've verified that the disk's cryptographic checksum is correct, you know the disk's content won't change so there's no need to recheck it (at least not for security purposes).

With USB stick that's not the case.

I know nothing about Ventoy, though.

...

Optical media was designed for distribution, ISOs and their use cases evolved around the same goal.

A good example is VirtualBox Guest Additions that packs several drivers for multiple OSs in a single ISO and leverages the autorun mechanism to simplify automation for end users.

Very enlightening.

Absorbed it at the time and followed up with experimentation ever since.

Edit: experimentation was underway long before this was published.

there's also a Part 2:

https://bkhome.org/news/202112/why-iso-was-retired-part-2.ht...

I have whittled away at the use-cases in favour of using the iso file,

Very well done, and I would rather not have to use ISO's myself since the only remaining thing they are perfect for is distribution, where it doesn't look like they will be beat for a very long time.

I would rather not touch ISOs any other time, but I'm going to have to maintain the skill anyway.

There's definitely nothing better for Windows than ISOs and Windows is huge with very sophisticated imaging built-in.

Kauler just happens to make an even more sophisticated IMG than most would do, for this distribution I can handle it with no drawbacks compared to a standard ISO file, and way better than a funky "hybrid" ISO.

"In theory" being the key word here. For whatever reason, it's a pita to use raw images with both virtualbox and VMware. You have to resort to third party command line tools to convert the image (qemu-img).

Honestly this is what makes a computer useful and removing it removes a significant amount of the utility of using a computer.

Now in this case where the user is root it might work out as an interesting balance in practise, I'm not sure.

Yeah that model is actually more secure than the standard Linux user model. There's also an option to run applications within their own containers.

Its stated that any app runs under its own user, including the browser.

Exactly. Though security is an onion, so it is at least making it harder.

In the traditional Linux desktop model a vulnerability may allow to run something as the user. It can change your bashrc, your application menu as well as your launchers, your browser extensions and settings. You may already have a user writable directory in your PATH so it can replace things even on a lower level.

https://xkcd.com/1200/

Don't forget curl |sh is everywhere, not to mention unaudited package management dependency trees.

It's why I think flatpak/snap kind of miss the actual problem: the only valuable data is the data the app is meant to handle. I don't actually care if they modify the system since I can reimage for free from the Internet at any point.

Nowadays I just have a full hard drive in a USB enclosure, but it was nice to have in the CD era.

It's like crypto: you wouldnt attract anyone paying nearly enough if you had to invest to solve current problems without any idea if you even could. Might as well re-solve inefficiently past problems and you might catch a few passer bys.

Getting persistence to work is a giant PITA lol I was doing it for work once and kept having problems. We used RUFUS, a Windows-only tool to make the drives. Making a new drive required Windows to format it, then Linux to copy the files, before it was usable. What a dumb process. I didn't use block-level imaging because I wanted to add new files easily or expand them to different drive sizes easily or something.

I remember using those features in Puppy around 2010. Never even heard of MX...

https://pendrivelinux.com/ is still around I see

Then click service like "Easy containers" and look at screenshots provided and then there is one having "Expert" tab - they don't provide screenshot of that and I bet there are at least 10 checkboxes.

Most likely if you are an expert you already have one liner ready to configure "Expert" stuff and you don't want to click checkboxes.

For power users. General users want this point and click thing, Windows/Mac got them used to it. It's sorta functional on mobile OS too. Its not like the CLI would (ever) disappear.

Everyone used slackware didn't they?

Slightly, I recall.

I'm not old, my beard just came out gray while I was waiting for all those USB sticks to boot since USB1 ;)

Kauler is brilliant.

I couldn't have gotten as far as fast once I found Puppy, because quite simply the fewer megabytes the size of the distribution, the faster the bootup.

And there was nothing else as small that booted all the regular Linux ways (including from FAT32 using Syslinux), and was worth being a user after you were booted :)

As for ISOs, more perfect images would be great.

For one thing they're wonderful for consistency, starting with the fundamental structure of partitioning & formatting which is copied bitwise identically from the master to the target as it overwrites the whole target. Simultaneously with all the user-oriented files within the file system, ideally it's like a forensic copy.

Also sometimes the boot files are finicky, or take a while to get right, and once it really works as robustly as possible on the master device, it would be perfect if every target device needed no attention whatsoever even though booting is very important to pay attention to. Not only will the exact user boot files be there on the target's resulting filesystem, the hidden boot records will too whether they are part of the filesystem or not. And further, the boot files in the filesystem will be at the exact same sector locations as the master. So will all the other files & folders. You can't get much more identical than that.

With bitwise copying, even the unused space within the filesystem will be copied verbatim from the master to the target, whether it contains zeros or vestiges of previously deleted data. And the filesystem is not even actually completely there until the bitwise image has finished copying to the target.

Just like an ISO was when you actually were burning to CDs, maybe at an earlier time than you were writing any USB drives.

And images are usually way faster than copying the exact same files by using an OS to copy them to a freshly formatted filesystem the regular filewise way. Whether copy & paste or CLI.[0]

I went through images backwards and forwards, have gotten a lot of reliable use out of it.

And you really can end up with equivalent performance either way.

When you do end up with the same performance that is :\

Turns out identical is not what you want with USB sticks.

more background

No matter of any "hybrid" approaches (even before UEFI) trying to make an ISO that could be directly copied to USB, modified ISO's are just not very good at copying to USB sticks and having them functionally boot like an ISO is supposed to do. Even when all the files and folders on the target end up fully accessible, performant, and error-free. It can be a frustrating thing.

Image files have a problem too, the hardware that the master image was saved from may be so dissimilar to the target media, that performance of that particular target, perhaps when interacting with other supposedly-compatible hardware such as motherboards, will be abysmal compared to the master device, and unpredictable across various motherboards.

Not such a big deal with HDDs and barely noticeable with SSDs but can really bring otherwise-satisfying USB devices to their knees. Sometimes yes, sometimes no. All targets within the same SKU as the master but some have slightly different controllers, firmware, or memory chips? Ruh-roh. Differernt SKUs on the USBs? I wouldn't be that confident any more.

Depends on how you handle the image file.

As long as you treat it like a standard ISO and mount it before copying filewise to a previously-prepared filesystem on a bootable USB stick, you should be fine :\

More or less what Rufus does automagically, he is brilliant too.

It does kind of defeat the purpose of having an image that's supposed to be copied bitwise directly to a target though.

Using dd or Etcher is so much quicker but then you're just playing the odds.

Decades ago for USB booting I used to think images were ideal.

But I was wrong.

Completely wrong.

Wrong about standards and I'm a standardization guy. How much more embarrassing can you get?

If it's supposed to be Linux (no matter whether DVDs or USBs become obsolete) ISOs boot using Isolinux, HDDs SSDs & USBs boot equivalently using Syslinux, and you can do it over a network using Pxelinux. These have all been very stable references for very long.

ISO files are an even older standard than Isolinux, which makes it even more fundamental so it's always been golden. Now I realize that. Everything that continues to trace back to this standard has a remaining chance to perform at least as reliably over the long term as ISO's have already performed so far. The continuity among Linux distributions using ISOs so far will be unmatched for decades to come no matter what happens. And ISOs were made for direct copying bitwise to their target media. Too bad it's just not right at all for very many USB sticks, so instead you have to first mount the ISO and copy the files & folders to an already-bootable previously-prepared USB drive. I'm not going to be regularly copying ISOs bitwise to optical disk devices any more (if I can avoid it), so in the future (starting quite a while ago) I'm not likely to use an ISO for what it was originally intended to do, if at all. Doesn't seem like anybody's going to be using ISOs to burn directly bitwise to media any more, which is the only reason ISO became the Linux standard for distribution to begin with, so why are ISOs needed going forward at all?

Too late, ISO (as the name implies) is now more valuable as a standard than it ever was for burning discs.

So now the further you go into the 21st century you really need the ISO's to keep working, more so than ever ! Even if nobody's burning discs. You can't make this up :]

And after exhaustively confirming that images are far less reliable for copying bitwise to USB sticks compared to ISOs when using optical, it leaves us back where we started without a worthwhile image file type than can always be overwritten to a USB whole-hog and have it boot. But at least you can still do it with DVD's using ISOs if you really have to, no different than ever.

Probably because an IMG (just like an ISO) is a filetype entirely focused on only one thing, writing it to a target device to make a perfect clone of the bitwise data pattern from one drive to another. Or to copy back to the same drive during a restoration event. Can't mistake that, it's either a true copy or not. Even if IMG is way older than ISO, it worked for floppies no different than it does today. The motherboard still just responds to whatever bit pattern it finds on the boot device, regardless of MBR, UEFI, EXTx, NTFS etc. I didn't think too much about it either, but there's a lot more electronics in between the motherboard and the bits residing on the storage medium for a USB than there was for a floppy. And a lot more "chance" for variation. Too bad IMG is not a standard filetype. But as long as it can be overwritten to the same device it came from and result in a perfect restoration from backup, it's job is accomplished with flying colors, and it almost never fails.

So if you're worried about the age of the filetype, IMG is so much more elderly than ISO that it was almost repressed bad enough to be forgotten (since not everybody wanted you to make perfect clones), which is probably why nobody came along to extend it for anything beyond everyday floppy use. Floppies worked just fine and were interchangeable without a detailed functional standard IMG filetype at all. But without a standard, IMG is just a filetype in name only which is why it's still the right file extension to use when you are going to be overwriting a whole drive of any kind with it later. That's exactly what it's for, and nothing else. And after a lengthy famine, there are now more brilliant tools that mount and handle wildly diverse IMG files simply because they are known to be a complete drive image. So all an IMG needs to do is behave like a drive image (as long as a particular IMG does that, no standard needed), it can be mounted and people are so much more familiar with VMs which helps a lot for those who've never used a floppy yet.

Barry is brilliant but others are too.

IMG works about as good on a whole hard drive as it did on a floppy, lots of USB's too when you're getting lucky. Hard drives have so much more in common with each other but they're not perfect either. But it's not ever been expected to work every time when the master and the target are less-than-identical hardware.

Remember at one time almost every IMG file was targeted to deploy on floppy media, approximately 1.44mb in size, containing 2880 sectors. Worked fine without a filetype standard then, and anything other than 2880 sectors would trigger the question "exactly what hardware am I supposed to write this file to?"

The thing about standards is, lots of people struggle if they aspire to meet a standard. You may or may not quite make it. But nobody says just because you conform, that you have to stop right there.

People generate millions by exceeding a standard when others are not. They can match others' work but others can not match theirs.

GRUB has got to be able to work too, it's under constant maintenance and has way more modern features.

And this Limine bootloader looks really promising. It has nowhere to go but up.

They've all got to work on every kind of Linux at least, with any other OS's being icing on the cake !

Less than that could be the result of a bug, maybe even a defect.

[0] Which filewise sometimes amount to a mere fraction of the GB actually transferred when done imagewise.

am glad i didnt have ur radar :)

if u were trying to check out a fast, small live linux distro without destroying ur windows partition, u had to run into puppy.

maybe u used linux in institutions where there was a sysadmin to do things for u.

Good point, thank you. Upvoted.

For Engineering examples, well, see the controversy around anything by Poettering (Systemd, PulseAudio, etc., etc.).

I love how you can’t get any sense out of them.

“So, you can see that software Y is almost unmaintainable in practice due to no maintainers wanting to work on ancient codebases?”

Yes.

“And you won’t maintain them?”

Yes.

“And you will not pay someone to maintain them for you?”

Yes.

“But you will staunchly fight the suitable FOSS alternative?”

Yes.

“Even if it means a constant relative decline in performance and options, not to mention evermore terrible workarounds?”

Yes.

Makes my head spin.

what Steve Balmer said about the iPhone

The first iPhone, running iOS v1, was kinda shit. It's easy to look at what the iPhone is today and laugh at Ballmer, but I don't think what he said was wrong at the time he said it.

https://www.youtube.com/watch?v=eywi0h_Y5_U

I think it is sort of different, though, Balmer was motivated to minimize the iPhone because they were his competition. It is an attempt to manipulate people. This odd thing where commenters online are never impressed by any tech thing, I’m not sure what the motivation is. They don’t even get a reputation for being so clever and jaded, because they are mostly pseudonymous.

Oh ok, I guess I probably won't give it a try then. I just like the look of the screenshots. Let the Linux GUI fragmentation carry on

He’s just doing it the Android way, separate user accounts for each application/binary.

The one critical thing with running as root in my mind is clobbering some storage in /dev.

Elsewhere in this thread the benefits are described , and im really curious if Linux could get a proper SAS/SAK working (your root password would only ever be entered into your trusted system login UI)

Just because it doesn't use any JavaScript doesn't automatically mean it's a good website.

So true.

All other things being equivalent, it can make the difference though, if only for the user.

+1 the homepage is a wall of blue links a-la mid-90s. Hard to parse visually.

Aren't malware nowadays targetting the home directory? with so many users installing executables, language interpreters or cloud management binaries in their homedir I wouldn't even bother trying to elevate privileges and/or infect /usr if I was writing a malware. Especially as all the interesting parts that are worth being stolen are also in the homedir.

This is DOA then for me.

Even on windows though there are some “administrator” level things that need escalated privileges to do.