https://docs.fedoraproject.org/en-US/iot/add-layered/#_install_multiple_packages

https://blue-build.org/reference/module/

You put together your layer as modules and rpm packages I believe, at least currently

Or package your whole solution into a flatpak

https://gitlab.com/eu-os/eu-os.gitlab.io/-/blob/ef4f8a93913db156840566e781302d2c2fbde7a1/goals.md#L23

It exists in various ways, eg.

• https://github.com/fastrizwaan/flatpak-wine
• https://github.com/tinywrkb/flatpak-wine-runtime

But one can't expect software to "just work" in wine, even when a lot of software currently do. If it's a serious deployment of a specific closed source commercial software drm'd from hell and back, get ready to have to contract crossover or similar wine vendors to oversee it and work their PE/winapi compat magic, or even contract the original vendor for a linux build.

So my take is let's not go there, let's try to wiggle out of vendor lock in whenever possible, as we see with openDesk and La Suite.

It's a bit of a chicken/egg question here. 23 years of survival is no small achievement and I think this project would definitely benefit from your input.

Personally I agree that there has been a lot of noise with people bickering about technical aspects of the POC, which distros are their favorites due to vague ideals and odd misinformation such as "ubuntu based means heavy", "rpm-ostree distros means no customization possible by user", all while ignoring technical requirements/concepts laid down by Robert for enabling collaboration between sectors and countries while maintaining stable deployment.

I also agree that for the long run, the legal and education process is paramount. Work has to be done to push against push backs from people who only wish to continue relying on US commercial solutions that has over the years, deeply rooted themselves and has been making themselves comfortable extracting capital; as well as on an education level, show people who are new to technology that alternatives are not necessarily janky, as what other would say.

And definitely not a lot of people can just work on this for free, time has to be spent putting food on table, people can volunteer extra/retirement time to work on this but that's not very sustainable.

So up to this point, I totally agree that an org has to be put together for the long run, to carry out education, lobbying, and handle funding for developer hiring, etc.

However, with regards to whether putting a functioning POC together should be the last step, after all the above has been done, I'm a bit skeptical. It seems that Robert so far has been able to get in touch with people from at least the Spanish education sphere. The way I see it, if the current POC being worked on here, can successfully be deployed at schools at least, with the help of more open minded IT teachers, expose next generations to it and show them that MS/Adobe/Apple eco systems are not the only way: linux/libreoffice/blender/kdenlive/gimp/krita etc. And see that these alternative ways are not there to extort them like their counter parts, and that they can even bring the solution they've learnt at school home and show their family, get involved as a hobby; it could raise awareness, get the ball rolling, help pave the way to putting together an org, get developers interested in the project, make it easier to secure public funding etc.

And personally I hope for once, people could actually stick together and get a linux distro going, without all the splitting at first disagreement.

At a glance this looks mainly Nextcloud+Moodle based https://gitlab.com/DD-workspace/DD#what-is-dd , and it seems that the focus is having it hosted on a server at an organization. Then to students, it is available though browser frontends. So it works as long as the system has a modern browser, not much to integrate yet going by their current scope.

One of DD's collaborators would be AirVPN, while their goal seems noble, they still provide paid services, so IDK what level of integration can be had with them, or whether they might be interested to introduce themselves here to propose something that aligns with the goal of this project.

@daniblues At the moment, these questions come to my mind:

• What kind of "inclusion" do you think would make sense for EU OS? Just a browser, or the whole backend?
• Do you think XNET would be interested in developing special OS level integrations besides just browser frontends down the road? Such as classroom computer control software?
• Do you think XNET would be interested in developing a EDU layer on top of EU OS current architecture? With a layer, they can definitely distribute their EU OS variant for EDU use.

Would also be interesting to see if XNET is interested in collaborating on base EU OS as well.

#3 (comment 2427560906) seems to suggest that LibreOffice will become a requirement for the demo

LibreOffice is a very powerful office suit, however when it comes to LibreOffice calc in particular, a lot of offices over the years have built workflows involving way too big spread sheets created in MS office, it might become a concern due to:

• slower performance relative to MS office https://ask.libreoffice.org/t/calc-low-performance-on-large-spreadsheet/61172
• needs a lot of memory to save large ods https://ask.libreoffice.org/t/trouble-converting-large-excel-spreadsheet/90197/6
• some spread sheet files requires VBA to function

For instance, I'm unsure if the edu sector would use overly large spreadsheet for years and years of book keeping on Windows 7 + MS Office 2003/2007, where LibreOffice would struggle on the same hardware.

This is a standalone issue thread as a continuation of #10 (comment 2417527111)

A reasonable hardware baseline avoids creating false expectations, but a bar set too high would perhaps reduce interest of potential adopters.

The baseline should also be descriptive enough so that people from multiple fields(hardware procurement, policy making, IT, etc.) can understand with good precision.

As discussed previously, runs smoothly on hardware procured for Windows 7 and later is really vague and up to interpretation due to:

• "Windows 7 hardware" is a very low bar, includes hardware that are perhaps not reasonable to support anymore such as i386(x86 32bit) with just 1GB of ram
• How to quantify "Smooth", should all (to be decided) required software be "smooth"?

The previous discussion can be roughly summarized as follow:

• "Windows 7 64bit" might be a better baseline, due to the trend of distros dropping 32bit support, less and less effort will go into 32bit support
• For this instance, we want to at least include hardware used by the Spanish edu sector: some 2009 intel quad cores, some 2014 amd thin clients and i3s, some other newer devices; it would be a good place for the POC to start
• 2GB ram might not be enough due to how much modern day web wants, needs some field test perhaps to see how well browsers behaves, ref: https://bugzilla.mozilla.org/show_bug.cgi?id=1532955 (both firefox and chromium are memory conscious, and will attempt not to grind the system to a halt)
• For smoothness sake, and the fact that legacy hardware support in linux (kernel and userspace) erodes over time, perhaps the line should be set a bit higher to avoid false expectations
• UEFI/Legacy boot support might be another consideration when it comes to deployment, perhaps a ref link to #7 , remember to test legacy boot over there

Hello,

As stated at legal-framework#2 (comment 2425352996), if I feel like I can contribute and am qualified to contribute through issues/pull requests, I'll do so that way. Thanks!

Hello,

Gitlab/Manage/Activity of inofficial EUOS Group shows that the user @rriemann joined and left the group.

This happened due to how gitlab invitation works https://docs.gitlab.com/user/project/members/#add-users-to-a-project https://web.archive.org/web/20250319061951/https://docs.gitlab.com/user/project/members/#add-users-to-a-project , where "invited" people are immediately added to your project, without any consent/action on the other party. The other party is expected to retroactively leave a project if they think that it was a mistake.

Gitlab email notification for being added to a project:

Law is definitely not my area of expertise, sorry for the disappointment but here's is my retroactive decline to the invitation, I'll be removing myself from the member list. Hope that you'll be able to find like-minded people with related expertise to help with your effort!

If I ever feel like I can and am qualified to contribute as a non-member, I'll do so through issue tickets/merge requests.

@arkadesOrg As said previously, whichever OS base is picked, eIDAS integration has to be added on top, and the effort to do so does not really differ between distros, be it Arch/Ubuntu etc.etc., due to the lack of existing effort in any distro.

So it’s unrelated to the OS base discussion, and further discussing it here distracts the original OS based choice discussion.

Whether eIDAS is essential/“janky without” to the EUOS demo should be discussed over at the eIDAS issue ticket, where the discussion is on topic. Keeping things on topic helps people joining and following the discussions, and keeps thoughts and ideas organized. Making a mess just deters people from participating, and sabotages productivity of the discussion.

@arkadesOrg As in, there is no existing distros with eIDAS integration, so it does not affect the base distro choice, because it is currently not possible to pick a distro that already has eIDAS integration.

Whichever distro is picked, OpenSUSE/Arch/Debian/Ubuntu etc.etc.etc., eIDAS software has to be added, so it is off topic.

This thread highlights a common issue in the Linux community: when a new distribution appears, enthusiasts often push their perfectionist ideals while losing sight of the project's purpose and target audience.

Totally agree, besides laying down a good baseline, the earlier this POC can be out of the door to show how beneficial having linux systems out there is (tho of course, not in a janky way), the better!

Multiple Distributions (Desktop, Server, Phone)

This should remain outside the proof of concept scope, though it might be worth considering for future development.

I agree with that too and personally I really don't see why supporting phones/desktop/server means separated distros bases/package management systems/build systems, and how it is so important at this stage.

Devices with proper modern linux kernels can go with systemd distros without issue, even ones with relative ancient kernels, porters over at Ubuntu Touch gets systemd working on various downstream kernels all the time.

Recent mobile devices also ship with a decent amount of ram, so using musl libc distros over glibc is not a strong requirement anymore to reduce ram usage, once again Ubuntu Touch devices just run full glibc, and hardly have problems with devices only having 4-8GB of ram with applications that were written/configured to be more memory conscious; I would even say mobile devices benefit from optimizations that can be found in glibc but not in musl libc in terms of battery efficiency. (not discrediting musl libc for focusing on correctness and simplicity of course, those are great goals!)

Debian/Mobian, OpenSUSE and Fedora already started having mobile device software packages on their main repo, pinephone images can be built from just, the main repo.

People also run Fedora on their Banana Pi routers without issues, and Alpine is hardly the choice for networking gear because there are multitudes of networking/firewall centric OSes out there.

Arch! Alpine! It must be a community driven distro! eIDAS!

Honestly I really don't see how community driven/company backed needs to be a consideration. If this ever go official, the amount of effort to officially audit and vet software packages should not really differ between a community driven and a company backed distro. For the POC, Fedora/Arch/Mint/OpenSUSE/Ubuntu/Debian/etc.etc. is really likely, fine. It just happens that bootc/rpm-ostree is at the moment, the most complete on Fedora, and it is a really solid system for immutable deployments. eIDAS integration is on the other hand, is not distro dependent at all, no distro currently ships eIDAS integration, why should it affect the OS base choice? Why not discuss eIDAS over at the eIDAS issue ticket?

@waffshappen Thanks for bringing up the a/b update requirement, 20GB would likely be too little for 2-3 layers of roll backs, something I've overlooked.

@rriemann at a glance, it is a pretty large range of hardware... let me try and summaries them a little bit through deployment feasibility, cpu + gpu, ram + permanent storage.

Deployment feasibility, legacy/UEFI:

2009 hardware might be problematic down the road, considering https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS, Fedora has been eyeing dropping legacy boot for quite a bit now, and who knows if they do it this year or next year, so depending on selected distro, custom deployment steps might be needed for legacy boot.

Some 2012 produced hardware gained UEFI support for windows 8 certification, however some of those hardware would only accept windows boot loaders due to hard coded paths, and might also have signature issues when it comes to secure boot that cannot be disabled properly.

2014 produced hardware with 2014 CPUs should support proper UEFI, however there are platforms that only support IA32 UEFI, but at the moment I don't see IA32 UEFI being dropped.

In this bracket, whether legacy boot is needed, whether there will be resources to carry out custom deployment would affect OS base choice.

CPU + GPU

2009 core 2 quads might still be able to stick around a little bit, however as you've listed youtube as one of the common web usage, as youtube moves away from lighter codecs to save on bandwidth, if a student wants to read a whiteboard that was filmed on camera, and try to push higher resolution VP9, the CPU will out right struggle, and the on motherboard GPU certainly cannot hardware accelerate VP9 decode.

2014 produced hardware, the i3 device on the list are at least 2014 haswell desktop class, so they should still be able to handle 1080 VP9, however some of the thin clients with the low power AMD APUs will have more issues than the core 2 quads, since those machines were designed to run remote desktop to a bigger server with older lighter video codecs. Getting those older video decode acceleration would also be a challenge on modern linux.

Bit of a non scientific reference, a desktop haswell i3 as the base line compared to the others: https://www.cpubenchmark.net/compare/2081vs1038vs2015vs2496/AMD-GX-415GA-SOC-vs-Intel-Core2-Quad-Q6600-vs-Intel-i3-4130-vs-AMD-RX-427BB.

Another note is that modern browsers are starting to rely more and more on newer graphics API for hardware accelerated rendering, and would fall back to CPU rendering on old hardware. (https://bugzilla.mozilla.org/show_bug.cgi?id=1731664)

In this bracket, these hardware will be able to display a KDE desktop, but draws the line of what "smooth" is.

ram + permanent storage

When ram has to be over provisioned, the first mitigation would be zram (on-memory compressed pages), then disk swaps (paging on permanent storage). For instance, it would be interesting to see how zram fairs in actual usage, so perhaps @rriemann you can enlist the help of Henry again to run some real tests with their classroom software set.

In most of the listing 4GB + hard drive/emmc was the most common. Ram determines how many software can be active before disk swapping happens, while the speed of the permanent storage determines how responsive the system will still be, once disk swapping has to happen. (also note the pitfall of systemd-oomd, the default on Fedora, if disk swapping affects overall system performance, it will start killing processes!)

Permanent storage itself also determines how fast programs launches, and generally affects the performance of modern browsers as they try to cache data.

This bracket also draws the line of what "smooth" is.

Drawing the line(s)

Depending on which of these hardware must be included, how "smooth", it could be:

X86_64

Including the Core 2 Quad, making legacy boot a requirement:

• 2009 2.4GHz Intel Core 2 Quad or better (x86-64-v2 distros ready! correction: Core 2 Quad lacks SSE4.2, however Nehalem architecture intel core cpus released in 2008 are x86-64-v2 ready), Directx9 supported gpu with mainlined linux drivers, 4GB ram, 20GB 32GB hard drive
• 2009 2.4GHz Intel Core 2 Quad or better, Directx9 supported gpu with mainlined linux drivers, 8GB ram, 20GB 32GB hard drive
• 2009 2.4GHz Intel Core 2 Quad or better, Directx9 supported gpu with mainlined linux drivers, 4GB ram, 20GB 32GB sata solid state drive

Not including the Core 2 Quad:

• 2014 3.4GHz Intel Core i3 or better, Directx11 supported gpu, UEFI support, 4GB ram, 20GB 32GB hard drive space
• 2014 3.4GHz Core i3 or better, Directx11 supported gpu with mainlined linux drivers, UEFI support, 8GB ram, 20GB 32GB hard drive
• 2014 3.4GHz Core i3 or better, Directx11 supported gpu with mainlined linux drivers, UEFI support, 4GB ram, 20GB 32GB sata solid state drive
• 2014 3.4GHz Core i3 or better with avx2 (x86-64-v3 distros ready! i3-4130 has avx2), Directx11 supported gpu, UEFI support, 4GB ram, 20GB 32GB hard drive

aarch64 / Armv8-A 64bit

• raspberry pi 5 or better, with drivers mainlined into kernel (rely on what kind of arm drivers upstream supports), opengl es3 or better gpu, 8GB+ ram, sdcard storage
• raspberry pi 5 or better, with drivers mainlined into kernel, opengl es3 or better gpu, 8GB+ ram, usb hdd storage
• raspberry pi 5 or better, with drivers mainlined into kernel, opengl es3 or better gpu, 4GB+ ram, usb ssd storage

To wrap up, I believe these requirement would directly affect OS base choice, and there might be more that I haven't thought of, and certainly more sectors to explore besides Spanish edu sector

Personally I think the "runs smoothly on hardware procured for Windows 7 and later" spec needs a bit of discussion and refinement, because "smooth" is very vague, and "hardware procured for Windows 7" is a bar that is lower than base Fedora, further lower than Fedora Workstation, and lower than what a lot of distros that were suggested so far, lower than what modern software produced for office use might want. And the refined requirement is integral to picking the base OS.

I agree that it likely needs further research to see how low the bar really ought to be for public and private office desktop use, whether new hardware should be procured anyway due to energy use, performance, hardware security requirements etc.

I see that there were some heated debate on the 32bit hardware support, and understand that various time_t and co changes would bring upon software recompiling required changes; distros would essentially have to release a new 32bit build with 0 compatibility with old software compiled pre-Y2K38 fix (unless some elaborate shim was made to bridge with the old ABI across kernel, libraries, libc), hence distros would like to take the opportunity to out right drop 32bit, making having 32bit hardware support in the spec rather undesirable.

So perhaps an explicit cut off for CPU like "4+cores 2GHz x86_64_v1"/"8+cores 2GHz armv8 64" should be named, which cut off should be taken tho is of course, needs to be further researched and discussed.

Other requirements should also be further discussed, considering public/private sector desktop usage, as outlined in the goal, as well as what baseline "smooth/reasonable productivity" is.

Another question regarding OS base selection I think this discussion ticket hasn't looked at is legacy hardware support.

One of the current spec is to "runs smoothly on hardware procured for Windows 7 and later"

What should be considered a "smooth" experience? How realistic is it to strive for "smooth" on windows 7 ready hardware?

While it's enticing for reasons like to reduce immediate E waste and lower immediate adoption cost, these requirements are below what current Fedora requires, and way below recommendation: https://web.archive.org/web/20200127222121/https://support.microsoft.com/en-us/help/10737/windows-7-system-requirements/ (disable javascript to display the archived page correctly)

• 1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor*

Should a 32bit supporting distro be picked instead, or should the bar be raised? Fedora nor some distros being suggested so far still provide 32bit builds, and some are even eyeing moving onto x86_64v2/v3, leaving early x86 64bit hardware behind

• 1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)

Fedora asks for 2GB, and having only 2 GB of ram would be rather unrealistic to run both KDE and a modern browser plus let's say a word processor, maybe some education software on top. Should the bar perhaps be rasied to like, 8GB of ram?

• 16 GB available hard disk space (32-bit) or 20 GB (64-bit)

Modern software also struggles with hard drives these days even on Linux, for instance, Firefox and Chromium takes a bit to spin up on slow storage, and would also struggle to load bigger web pages as it uses permanent storage for caching. KDE itself takes a bit to load assets from hard drive. To make it worse, with the ram requirement being low, permanent storage would be used for paging/swapping, slowing down the system even more.

@FrederikSchack personally I agree that the EU desperately needs digital sovereignty.

Tho for this instance, an OS as the goal, with the base OS being debated by the fledging community, will the EU put resources into it? Will the EU do it right? Will the EU try but turn it into an insecure multilayer outsource hell?

Those are the questions I was trying to ask.