Anyways, AmigaOS is such a mess with all the “forks” that are around already...
* BetterWB
* BestWB
* ClassicWB
* AmiKit with all its incarnations
* CoffinOS
* OS 3.X
* OS 3.9, with or without various official and inofficial boingbags
* OS 3.5 which is still used for some weird reason
* OS 3.0 which is still used as it was default for most A1200 and A4000 systems
* OS 3.1 with its various incarnations
* OS 3.1.4 which has limited user base

At least with Linux, I can pick a distro and stick with it, without any conserns about legality and other nonsense. For soon 20 years I have been using Gentoo, on all kinds of hardware, even 68k Amiga.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

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

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

What relevance does that video have?

And OS 3.2 will come with a new “do-it-all” kickstart component akin to systemd, aptly named System-Startup... from the guy who made this borken piece of software
http://aminet.net/package/util/shell/ViNCEd_Boot_Shin (shin, shim... what’s the difference...)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Most people don't considering just the kernel as operating system, when talking about Linux they most often talking about all different distributions and package management system.

Personally find it bit confusing to know what fork of macemu or some other thing on github, because there is lots repos with different changes are move it different directions, so just getting some overview what this changes are, if this changes will be good for a AmigaOS version of Basilisk, is whery time consuming work.

With the Linux kernel it works because there is someone a boss that is responsible for merging everything.

Last edited by NutsAboutAmiga on 26-Oct-2020 at 03:11 PM.
Last edited by NutsAboutAmiga on 26-Oct-2020 at 01:22 PM.
Last edited by NutsAboutAmiga on 26-Oct-2020 at 01:20 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@kolla

Quote:

And OS 3.2 will come with a new “do-it-all” kickstart component akin to systemd, aptly named System-Startup...

I was going to comment on this, but I think I'll just sit here and eat popcorn for a while.

At least we still have OpenRC and runit.

_________________
"Unix is supposed to fix that." -- Jay Miner

@NutsAboutAmiga

“most people”? I though the crowd here were people who have computers as a passion and a hobby and hence do not fall under the “most people” category. Matthey is certainly not a “most people” person, at least he should know the difference.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla Quote:

kolla wrote: @matthey https://www.kernel.org https://github.com/torvalds/linux (And if you wish to display your ignorance about how workflows are done with git by pointing at the thousand of forks of the repo on github, then go ahead)

So what? I don't think that you have understood what matthey said.

It's a matter of fact that there are plenty of Linux (and here the context was not only about the kernel, but any distro or project which is derived by the base kernel sources) forks, which has nothing to do with the fact that there's a central repository for the project.
Quote:

Oh - the sources above also build and run on real Amiga hardware.

Who cares in this context?

@kolla Quote:

kolla wrote: @NutsAboutAmiga What relevance does that video have? And OS 3.2 will come with a new “do-it-all” kickstart component akin to systemd, aptly named System-Startup... from the guy who made this borken piece of software http://aminet.net/package/util/shell/ViNCEd_Boot_Shin (shin, shim... what’s the difference...)

What's the problem with systemd? Are you another systemd hater?

@kolla

Quote:

Anyways, AmigaOS is such a mess with all the “forks” that are around already...

You forgot another distribution:

AmigaSYS

Last edited by amigakit on 26-Oct-2020 at 09:25 PM.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@cdimauro

No, wrong - distros do most often maintain patches to mainline kernel, but this is NOT forking - they keep patches to minimum and rebase to mainline all the time.

Forking is what OpenBSD did when they split from NetBSD.
Forking is what DragonFlyBSD did when splitting from FreeBSD.

I honestly cannot think of any fork of Linux, and the “fork hell” statement is ridiculous and does nothing but display utter ignorance.

AmigaOS is a heck lot more forked than Linux is, here we talk about entirely different lineage of development and partly incompatible branches of the OS with no hope in sight for unification, and a handful of besserwissers who see it as their task in life to prevent anyone else from laying eyes on the oh so holy mess that is the OS sources. And who gave these guys blessing to take this mission upon them? Remember how Hyperion had to change “All rights reserved” to “Developed under license”? Yeah, and as anyone knows, licenses can be revoked.

And then we have to start over again, another damn fork.

Last edited by kolla on 26-Oct-2020 at 11:52 PM.
Last edited by kolla on 26-Oct-2020 at 11:51 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla Quote:

kolla wrote: @cdimauro No, wrong - distros do most often maintain patches to mainline kernel, but this is NOT forking - they keep patches to minimum and rebase to mainline all the time.

Which is the definition of forking. Otherwise you ask to merge your patches to the mainline ASAP, right?

Patches are locally maintained by developers only for a limited time. Having patches to be continuously rebased is a pain in the neck, especially with a moving target like Linux, which has no stable APIs neither ABIs, and an enormous code-base.

You should know of what I'm talking about, if you're a developer.
Quote:

Forking is what OpenBSD did when they split from NetBSD. Forking is what DragonFlyBSD did when splitting from FreeBSD. I honestly cannot think of any fork of Linux, and the “fork hell” statement is ridiculous and does nothing but display utter ignorance.

That's because of your ignorance.

Please, tell me about Devuan which was explicitly forked from Debian by the systemd-haters. As well some other known distros, like Slackware and Gentoo, which AFAIR are still refusing to move to the dark side (systemd).

systemd is another HUGE project with a big code base (it's considered a meta-os), and maintaining a fork of Linux (because that's what is substantially required) with TONs of patches just to keep the Sys-V Init ecosystem is a BIG burden.

But it's just a matter of time: the more systemd and SysV Init diverges, and the more it'll be difficult to maintain such big fork, so at the end those stupid fanatics will be forced to raise the white flag and there'll be only systemd left.

This is just an example (albeit the most important) to show that yes, there are forks of Linux. As well as there are much more forks of the Linux ecosystem, because different distros have different components which stay on different repositories: from the Desktop Environment to the GUI libs & toolkits, passing to the packet managers and the shell terminals, those are typical "Olympic" specialties in the Linux land...
Quote:

AmigaOS is a heck lot more forked than Linux is, here we talk about entirely different lineage of development and partly incompatible branches of the OS with no hope in sight for unification, and a handful of besserwissers who see it as their task in life to prevent anyone else from laying eyes on the oh so holy mess that is the OS sources. And who gave these guys blessing to take this mission upon them? Remember how Hyperion had to change “All rights reserved” to “Developed under license”? Yeah, and as anyone knows, licenses can be revoked. And then we have to start over again, another damn fork.

I know all of this, but it's a little thing compared to what happens in the Linux land.

Quote:

kolla wrote: AmigaOS is a heck lot more forked than Linux is, here we talk about entirely different lineage of development and partly incompatible branches of the OS with no hope in sight for unification, and a handful of besserwissers who see it as their task in life to prevent anyone else from laying eyes on the oh so holy mess that is the OS sources. And who gave these guys blessing to take this mission upon them? Remember how Hyperion had to change “All rights reserved” to “Developed under license”? Yeah, and as anyone knows, licenses can be revoked.

If Linux is fork, flavor, patch, configuration chaos hell then the Amiga purgatory is The Void. Vast emptiness, with nobody left. Yes, the Amiga is plagued by many of the same problems even though most APIs are similar. At least Linux uses the POSIX standard like most UNIX forks.

Last edited by matthey on 27-Oct-2020 at 07:03 PM.
Last edited by matthey on 27-Oct-2020 at 07:32 AM.

@cdimauro

Quote:

Which is the definition of forking.

No it is not, it is called maintaining a patchset outside of main.

Forking is when you split off completely.

Yes, maintaining a patchset can LEAD to a fork, if the patchset gets too big or too diverged from main - but when did that last happen with Linux? Ever?

Quote:

Otherwise you ask to merge your patches to the mainline ASAP, right

And this also happens all the time.

Quote:

Patches are locally maintained by developers only for a limited time. Having patches to be continuously rebased is a pain in the neck, especially with a moving target like Linux, which has no stable APIs neither ABIs, and an enormous code-base.

git makes it rather simple to rebase... that was one of the goals with git in the first place, to make it easier to develop and maintain outside of main branch.

Oh, and APIs are very stable - you may have several to chose from, but in general they are quite stable. Problems arise when developers do "magic" outside of the APIs... but this is a problem on ANY operating system.

Quote:

You should know of what I'm talking about, if you're a developer. Quote: Forking is what OpenBSD did when they split from NetBSD. Forking is what DragonFlyBSD did when splitting from FreeBSD. I honestly cannot think of any fork of Linux, and the “fork hell” statement is ridiculous and does nothing but display utter ignorance. That's because of your ignorance.

How appropriate, you fight like a cow.

Quote:

Please, tell me about Devuan which was explicitly forked from Debian by the systemd-haters. As well some other known distros, like Slackware and Gentoo, which AFAIR are still refusing to move to the dark side (systemd).

Wow... "the dark side"? Look who's the hater! For your information, Gentoo has been supporting systemd since the very early days, but it was always optional. Thanks to this "refusal" to just jump on the band-wagon, many aspects of systemd was reimplemented, and many flaws and bugs in the systemd components were also uncovered and fixed - it has been a mutually beneficial process.

For what it is worth, I am not a so called "hater", systemd is more like job security for me, it generates tons of work as "most people" struggle to fathom the concepts it brings and find it difficult to write proper unit files. So my relation to systemd is strictly professional, I can do it when I get paid, but at home with my own systems, I chill and relax with linux and BSDs that don't use systemd. And my desktops don't use systemd either, as they are macs these days, and use the "original systemd", launchd... which isn't that different.

Quote:

systemd is another HUGE project with a big code base (it's considered a meta-os), and maintaining a fork of Linux (because that's what is substantially required) with TONs of patches just to keep the Sys-V Init ecosystem is a BIG burden.

Well, luckily, there is no reason to stick with Sys-V init, there are several alternatives.

Quote:

But it's just a matter of time: the more systemd and SysV Init diverges, and the more it'll be difficult to maintain such big fork, so at the end those stupid fanatics will be forced to raise the white flag and there'll be only systemd left.

SysV-init is not diverging anywhere, it just is what it is, a glorified exec().

But it's not a matter of maintaining forks, this is not about forks, this is about which init system to use, of which there are several to choose from. Nothing magic. Systemd is one that strictly RELIES on Linux though, while for example OpenRC maintains posix compliance and is also the init system for other operating systems, like BSD based TrueOS.

Quote:

This is just an example (albeit the most important) to show that yes, there are forks of Linux.

Except what you write about are NOT forks. When one distro splits into two distros because of diverging views and focus, they are not forks of the software they use, the code base is the same.

Quote:

As well as there are much more forks of the Linux ecosystem, because different distros have different components which stay on different repositories: from the Desktop Environment to the GUI libs & toolkits, passing to the packet managers and the shell terminals, those are typical "Olympic" specialties in the Linux land...

And again - picking different sets of software, packaging system, DEs and toolkits... this has nothing to do with "forking".

Quote:

Quote: AmigaOS is a heck lot more forked than Linux is, here we talk about entirely different lineage of development and partly incompatible branches of the OS with no hope in sight for unification, and a handful of besserwissers who see it as their task in life to prevent anyone else from laying eyes on the oh so holy mess that is the OS sources. And who gave these guys blessing to take this mission upon them? Remember how Hyperion had to change “All rights reserved” to “Developed under license”? Yeah, and as anyone knows, licenses can be revoked. And then we have to start over again, another damn fork. I know all of this, but it's a little thing compared to what happens in the Linux land.

Nonsense. In "Linux land" everything is out in the open, and anyone is free to pick the path that best suits them. Just look at your own argumentation for systemd above... systemd can very well become "the one and only" init for Linux - but then it is through a democratic process where developers and users alike take part. Unlike on Amiga, where such changes are dictated by just a few.

Last edited by kolla on 27-Oct-2020 at 08:51 AM.
Last edited by kolla on 27-Oct-2020 at 08:47 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

nyone is free to pick the path that best suits them. Just look at your own argumentation for systemd above... systemd can very well become "the one and only" init for Linux - but then it is through a democratic process where developers and users alike take part. Unlike on Amiga, where such changes are dictated by just a few.

That is the strengh of GNU/Linux Systems compared to proprietary source code OSes.

_________________
"Unix is supposed to fix that." -- Jay Miner

@kolla

Quote:

And OS 3.2 will come with a new ?do-it-all? kickstart component akin to systemd, aptly named System-Startup..

I don't know exactly what that means but what OS3.2 needs and OS4 should have had in the beginning is something like fstab.d and other dirs. That is, in the case I'm thinking of, directories for startup scripts and assigns. User-Startup should be as obsolete as Mountlist by now. It's a convulted mess and installing programs would be easier without it. They need a dir for each program to save a script in. After all, this how they started to organise things in OS2. Single files with multiple data were split up into modular components as multiple files. Multiple scripts and assigns should have the own dirs. And the ability to assign by looking for a progdir assign dir just the way fonts and libs can be stored locally.

@Hypex

What I suggested at the 1998 DevCon was a preferences IFF file format for assigns so that they could be queried and manipulated easily by the installer and other applications. Since the installer already was designed to make and remove lines of text from user-startup, it got nixed.

I also proposed that the AmigaDOS shell be replaced by an AmigaVision flow-editor style GUI and its scripts into the corresponding IFF format. That never made it off the ground either because AmigaVision was a private-label contract deal that Commodore never owned the sources to.

@matthey Quote:

matthey wrote: Quote: kolla wrote: AmigaOS is a heck lot more forked than Linux is, here we talk about entirely different lineage of development and partly incompatible branches of the OS with no hope in sight for unification, and a handful of besserwissers who see it as their task in life to prevent anyone else from laying eyes on the oh so holy mess that is the OS sources. And who gave these guys blessing to take this mission upon them? Remember how Hyperion had to change “All rights reserved” to “Developed under license”? Yeah, and as anyone knows, licenses can be revoked. If Linux is fork, flavor, configuration chaos hell then the Amiga purgatory is The Void. Vast emptiness, with nobody left. Yes, the Amiga is plagued by many of the same problems even though most APIs are similar. At least Linux uses the POSIX standard like most UNIX forks.

Please, don't let me laugh matt: Linux is NOT POSIX-compliant!

And you know who did/don't want it? Its dictator (for life).

It' better that you seek for something different if you want to use a POSIX-compliant o.s..

@kolla Quote:

kolla wrote: @cdimauro Quote: Which is the definition of forking. No it is not, it is called maintaining a patchset outside of main. Forking is when you split off completely. Yes, maintaining a patchset can LEAD to a fork, if the patchset gets too big or too diverged from main - but when did that last happen with Linux? Ever?

I've already told you: Devuan. It's even reported on their site, at very beginning (first sentence!) of their home page:
"Devuan GNU+Linux is a fork of Debian without systemd"
Quote:

Quote: Otherwise you ask to merge your patches to the mainline ASAP, right And this also happens all the time.

Oh, yeah, I see. Then please contact Devuan's developers and ask them to merge their patches on the mainline.
Quote:

Quote: Patches are locally maintained by developers only for a limited time. Having patches to be continuously rebased is a pain in the neck, especially with a moving target like Linux, which has no stable APIs neither ABIs, and an enormous code-base. git makes it rather simple to rebase... that was one of the goals with git in the first place, to make it easier to develop and maintain outside of main branch.

The fact that git makes the life simple does NOT mean that rebasing a (big) project is simple. Elementary logic at hands.

When at BMW we moved to a major Yocto update it required A LOT of work (and time), since we have our customizations on top (included systemd).

Maybe for you a "git rebase master" is enough, but once you have conflicts you have to solve them, and the more complex is a project, the more contributors there are, the more difficult it will be to have everything rebased AND working.
Quote:

Oh, and APIs are very stable - you may have several to chose from, but in general they are quite stable. Problems arise when developers do "magic" outside of the APIs... but this is a problem on ANY operating system.

Then talk with the drivers developers and ask them how easy is to develop & maintain a driver for Linux, compared to the other o.ses which have stable API & ABI.
Quote:

Quote: That's because of your ignorance. How appropriate, you fight like a cow.

Should I remind you that it was YOU the first that blamed someone else, tell him that he's ignorant?
Quote:

Quote: Please, tell me about Devuan which was explicitly forked from Debian by the systemd-haters. As well some other known distros, like Slackware and Gentoo, which AFAIR are still refusing to move to the dark side (systemd). Wow... "the dark side"? Look who's the hater!

https://www.collinsdictionary.com/dictionary/english/sarcasm

It's quite evident that you're not informed about the climate of the Linux/Unix community due to systemd, with its developers that were even menaced of death by some fanatics "purists".
Quote:

For your information, Gentoo has been supporting systemd since the very early days, but it was always optional. Thanks to this "refusal" to just jump on the band-wagon, many aspects of systemd was reimplemented, and many flaws and bugs in the systemd components were also uncovered and fixed - it has been a mutually beneficial process.

Let's see how long this can continue.
Quote:

For what it is worth, I am not a so called "hater", systemd is more like job security for me, it generates tons of work as "most people" struggle to fathom the concepts it brings and find it difficult to write proper unit files. So my relation to systemd is strictly professional, I can do it when I get paid, but at home with my own systems, I chill and relax with linux and BSDs that don't use systemd. And my desktops don't use systemd either, as they are macs these days, and use the "original systemd", launchd... which isn't that different.

systemd is quite different from long time, and it became a "meta-os", as I said before. Does luanchd integrates udev? Just to mention another important system component which was assimilated (cit.) by systemd, and caused other harsh reactions by the "purists"...
Quote:

Quote: But it's just a matter of time: the more systemd and SysV Init diverges, and the more it'll be difficult to maintain such big fork, so at the end those stupid fanatics will be forced to raise the white flag and there'll be only systemd left. SysV-init is not diverging anywhere, it just is what it is, a glorified exec(). But it's not a matter of maintaining forks, this is not about forks, this is about which init system to use, of which there are several to choose from. Nothing magic. Systemd is one that strictly RELIES on Linux though, while for example OpenRC maintains posix compliance and is also the init system for other operating systems, like BSD based TrueOS.

When I've written diverges it was about systemd vs SysV-init. SysV-init can continue on its own, of course, but the introduction of systemd as the default init system on Linux caused the forks that I've talked about.
Quote:

Quote: This is just an example (albeit the most important) to show that yes, there are forks of Linux. Except what you write about are NOT forks. When one distro splits into two distros because of diverging views and focus, they are not forks of the software they use, the code base is the same.

Sorry, but the code base of systemd-base distro IS different from another one which is still using SysV-Init. And it's the reason why the forks happened: see above the devuan site, and its documentation about it.
Quote:

Quote: As well as there are much more forks of the Linux ecosystem, because different distros have different components which stay on different repositories: from the Desktop Environment to the GUI libs & toolkits, passing to the packet managers and the shell terminals, those are typical "Olympic" specialties in the Linux land... And again - picking different sets of software, packaging system, DEs and toolkits... this has nothing to do with "forking".

Can you tell me how many packaging systems, DEs, toolkits, etc. are found on MacOS X and Windows after a fresh install?

And just for fun, search "fork" here: https://en.wikipedia.org/wiki/GTK
Quote:

Quote: I know all of this, but it's a little thing compared to what happens in the Linux land. Nonsense. In "Linux land" everything is out in the open, and anyone is free to pick the path that best suits them.

And free to fork at any time that there's a divergence on opinions. See the above link.
Quote:

Just look at your own argumentation for systemd above... systemd can very well become "the one and only" init for Linux - but then it is through a democratic process where developers and users alike take part. Unlike on Amiga, where such changes are dictated by just a few.

Please, don't let me laugh you too. As I said before, Linux is NOT POSIX-compliant only because of the arrogance of its dictator.

And that's not the only example in the Linux land. I can cite the maintainer of glibc, which refused some patches to improve the support of ARM because he hates this architecture, and it caused the interested peoples to start another project for replacing glic.

Or you can ask GCC maintainers why they refused to integrated some simple patches in order to make it working with case-insensitive filesystem. It took me ONE WEEK to figure-out why building GCC on my system was generating weird results, and only by luck I found a web page talking about it.

So, please, stop using the "democracy" word: it's not appropriate here.

Last edited by cdimauro on 27-Oct-2020 at 09:26 PM.

@Samurai_Crow Quote:

Samurai_Crow wrote: @Hypex What I suggested at the 1998 DevCon was a preferences IFF file format for assigns so that they could be queried and manipulated easily by the installer and other applications. Since the installer already was designed to make and remove lines of text from user-startup, it got nixed. I also proposed that the AmigaDOS shell be replaced by an AmigaVision flow-editor style GUI and its scripts into the corresponding IFF format. That never made it off the ground either because AmigaVision was a private-label contract deal that Commodore never owned the sources to.

The IFF format for those kind of things isn't recommended, since it's binary.

A text format, like the unit files mentioned by kolla and that used on systemd, is a much better candidate.

@cdimauro

There are many counterexamples to your assertion that text files are preferable: Text files are not locale supported. Some assistive technologies are limited to a pointing device. On-screen keyboards are difficult to use by quadriplegics whose input device consists of a light pen like device mounted on the side of their heads that they click with their teeth. Text files are more difficult to parse for the machine than binary which is why Python and Java use bytecodes for their code executables. I could go on and on.

@Samurai_Crow Quote:

Samurai_Crow wrote: @cdimauro There are many counterexamples to your assertion that text files are preferable: Text files are not locale supported. Some assistive technologies are limited to a pointing device. On-screen keyboards are difficult to use by quadriplegics whose input device consists of a light pen like device mounted on the side of their heads that they click with their teeth. Text files are more difficult to parse for the machine than binary which is why Python and Java use bytecodes for their code executables. I could go on and on.

You can continue but I think that you forgot the application context: defining metadata (included workflow) about components to be loaded/executed at boot time (and controlled after that).

Text files (in a proper format: it's not free text!) are the best compromise from this PoV. Take a look at systemd unit files, and you'll see how and why.

A binary format is the last thing that should be use for it.