You are not logged in.
I never intended this to turn to a mud slinging contest. Fellas, this merge is not a hill to die on. That isn't even my true concern, my concern is whether or not the people behind dpkg will actually get it together and do what it takes to prevent problems with it, because problems at the stream source effects EVERYTHING downstream. Not just us.
The merge has already happened for bookworm, it is now the default and the only supported configuration.
https://lists.debian.org/debian-devel-a … 00001.html
https://bugs.debian.org/cgi-bin/bugrepo … bug=978636
FWIW dpkg seems to work fine in my bookworm system. Have you had any problems with merged /usr in your derivative?
And have you read this:
Booting Without /usr is Broken
There seems little point supporting a fundamentally broken paradigm.
I have not, but the dpkg dev leaving ominous, passive-aggressive warnings for merged /usr folks is disturbing, and does not instill confidence.
I suppose, best I can do is get timeshift. Backups are good practice, anyway....
Is it worth trying Peppermint on a BananaPi M5?
Does it have any way to use UEFI? Via u-boot or otherwise? As of right now it's an ISO, nothing as of yet to migrate existing systems to PepOS
Full disclosure: I'm indifferent about /usr merge unto itself, it's the following issue that has me increasingly scared and worried.
This article details a growing conflict between debian and the dpkg maintainer over the /usr merge: https://lwn.net/Articles/890219/
This scares me, because if dpkg suddenly stops working properly, we are *all* in trouble: Kali, LMDE, AntiX, Dpup, and many others would be badly hit.
Today, it's simply packages like live-boot that have problems. Tomorrow, it becomes far, far worse. Such is my fear.
Thoughts?
I've tried using finit, be warned it isn't complete yet. the automation of the init scripts being properly configured hasn't been added in, and it conflicts with the "init" package
All in a day's work, friend
I'd be interested in trying an ARM release on my Raspberry Pi 4.
Just be aware, this is a full-fledged live ISO, one of few in existence for this architecture.. You'll need the UEFI firmware from the link below in order to use it. I've tested earlier versions on my own Pi, so I know it works. If you need help, let me know!
https://github.com/pftf/RPi4
Woah, Kudos to you, HOAS! Didn't think my silly idea would actually get anywhere, glad to see it coming to life!
@fsmithred, this issue did not properly land in debian/devuan. I am having issues with this bug still
I was waiting for @zappers input from our discussion before making the suggest of JWMKit as a possibility for this repository, but I see he already jumped in head first.
I guess he's quicker to action than I am. Thanks
JWMKit is not in the Debian repository and the project was originally release here on these forums as a Refracta build of Devuan. I do maintain debs so it should be easy to add to the repository and keep up to date.
I think it would also be nice to see things like JWM themes in the repository, and custom Devuan wallpapers, icons, etc. Or archives of older Devuan artwork that is not in the current release.
Also having the repository would help deliver the newest versions to the user of my Devuan based JWMKit Linux.
So what does JWMkit....do?
Full Disclosure: I act alone in this, this is not put on by the Devuan team themselves.
I would like to know who all here has software they have or would like to package for Devuan, but can't due to the limitations on Devuan's official resources. This is following up on the end of the discussion in "My crappy radio player". This is intended to get a better idea of how much "community" software would be out there for Devuan, and whether or not it's enough to make a dedicated community repository worthwhile.
Again, this is a PRELIMINARY survey, nothing is set in stone yet, I just want to get a feel of the total extent.
Perhaps someday, if I get the money/time/resources, I might host a "Devuan Community Repository" that would host all of the community-made stuff, so we can have it all in one easily-accessible place
MrReplikant wrote:This would make a lovely addition to Devuan, I think. Maybe talk to the powers that be on the packaging side to have this added? If you're willing to maintain it?
Yours is not the first such request. There are many attractive and useful user-contributed "extras" but they are unlikely to ever be added to devuan itself. Why? Our mission is to provide Debian without systemd . . . full stop.
Fair enough ¯\_(ツ)_/¯
This would make a lovely addition to Devuan, I think. Maybe talk to the powers that be on the packaging side to have this added? If you're willing to maintain it?
I FUCKING DID IT!!! I GOT INTO THE BIOS AND CHANGED BOOT ORDER HECK YESS!! But didn't install to 1GB disk, it's probably die in a year anyway. NAND FLASH what could I expect? So I installed devuan into an SSD in another pc, then put it inside.
Congrats, friend :-)
Zephyr, were you aware that there is an experimental calamares-settings-devuan package built by me? It's the best place to start, I think, as that is where all the "Debian" branding is placed. You can find the GitHub repo here: https://github.com/MrReplikant/calamares-settings-devuan
If you need any help at all, do not hesitate to contact me.
Are you able to change these lines at all?
Which suite of Devuan do you wish to install? I presume Bullseye's Devuan counterpart,Chimaera?
if so, this is the line you need:
deb https://pkgmaster.devuan.org/merged chimaera main contrib non-free
deb https://pkgmaster.devuan.org/merged chimaera-security main contrib non-free
MrReplikant wrote:since Power ISA got open-sourced, there's an initiative to bring that back
Unfortunately POWER10 brought in a requirement for non-free firmware in the memory controller chips:
https://www.devever.net/~hl/omi
Not that it really matters because any POWER9 machine (or any of the "open" platforms you list) will need a hard drive and that drive will have a controller running proprietary code below ring 0. The battle is already lost.
MrReplikant wrote:the recent release of the Alibaba Roma RISC-V laptop
RISC-V is nice but the specification does allow for non-free extensions and I'm sure most, if not all, manufacturers will take advantage of that. To presume otherwise is naive.
MrReplikant wrote:My conclusion is, if we can work to keep our old (or simply pre-lockdown) hardware working long enough, say maybe another 10 years (depending on the device), we can wait this out long enough for those devices to become a bit more accessible to the common folk.
It seems to be getting worse rather than better but whatever.
I am not saying any of those options are perfect, and notice that I never claimed such. But what we are left with is either that, or hardware that is fully locked-in and monopolized. Which would you prefer? All I'm saying is that in time, *hopefully*, these devices will become less expensive/more accessible.
In the meantime, to stave this issue off, we need to look at how to make Devuan more efficient and/or find more workable alternatives to programs that are becoming increasingly bloated.
Maybe I'm crazy. Maybe it's futile. But i'll die screaming and go down fighting before I let Apple or Microsoft claim victory over us or the Linux Community. After all, isn't that stubbornness what got us this far in the first place, in a way?
Just edited it into the last thing. But yeah, after sleeping on it last night, I think I know now what our best course is, for the time being. Many, many initiatives are up and coming to get us more open hardware. There's the MNT Reform, Pocket Reform, the Librem 15, Pinebook, and not to mention that since Power ISA got open-sourced, there's an initiative to bring that back, too, atop the recent release of the Alibaba Roma RISC-V laptop. My conclusion is, if we can work to keep our old (or simply pre-lockdown) hardware working long enough, say maybe another 10 years (depending on the device), we can wait this out long enough for those devices to become a bit more accessible to the common folk. It won't be easy, but we're without other options at the moment. We can't buy these locked-down devices, that will only encourage Microsoft and Apple to keep doing it.
I never did care for KDE anything, and I've actually tried over the years - those folks seem to think on a very different wavelength than me. TBH, I never cared much for XFCE either - I've been using MATE for years. It is probably too 'heavy' for some, though not that much more than XFCE. It is a full DE - it is the fork of Gnome 2.
It seems to me that a simple WM-based option at install time would be welcome for those with older/resource-limited HW. A nicely set up IceWM or something like that, or one of the *box wm's? I mean, you can install just about anything on Devuan after the fact, but setting it up to be decent looking and reasonably functional sometimes seems a bit fiddly. A nicely setup WM at installation would be a useful offering it seems.
Always been a MATE man myself, though XFCE 4.18 will soon make it a damn-close second, since it will finally add in recursive search in thunar and fuller date-time functionality. Still, I agree wholeheartedly, we need to look into a dedicated WM task, and I think more research is definitely warranted.
I, personally, don't like AntiX's implementation, solely on the fact that working with files is...not particularly user-friendly, especially for people like me who are used to the "windows" file management style of things. But, hey, I'll give them credit where it's due: they DID manage to make the icewm/jwm menu much more friendly. Props to them for that.
I think maybe we would be better suited looking at the Bunsenlabs or Puppy Linux Implementations
I always thought it was a good idea but these days Plasma is very nearly as light as openbox/tint2 and is *much* prettier and more user friendly (IMO).
This is what I keep hearing, but how the heck does it accomplish this? I have done a fair bit of fooling with plasma and I still can't figure that out for the life of me. Perhaps you can enlighten me?
MrReplikant wrote:You're welcome to test.
I've just ordered a TTL USB cable so I will do that as soon as it arrives.
Good deal. Also, just edited the post to fix the whole UEFI spiel.
Edit: Oh man, that's unfortunate.
I think to remember that my BananaPi boots legacy.
It has the isolinux boot on it, so it *might* work, I'm not sure.
MrReplikant wrote:Also note that because no ARM machines with legacy boot were ever produced, installations will be UEFI-only
Just FYI: my ROCK Pi S aarch64 board does not support UEFI and I'm sure there are others that don't.
Might I ask where the source for the ISO image is? The GitHub repository tarball only contains the README.md file.
the source code is not fully complete yet, the final step is still being reworked. It *does* have the isolinux loader on it, so it *might* support legacy, but I'm not sure. You're welcome to test.
Good Morning,
I have successfully forked the installer-iso program and have gotten it working well enough to produce proper (read: not just mini) ISOs for Devuan on ARM64. I have successfully built the netinstall ISO, which should allow a minimal base system to be installed without internet connection. Do note that the Desktop and Server ISOs are also in the pipeline and will be released soon as well.
Do also note, Raspi 4 and 3 can also run this if they are using the UEFI firmware that was made for them on GitHub, I have tested such myself and am running standard Devuan on my Pi 4.
You can find the netinstall ISO here!
https://github.com/MrReplikant/Devuan-Arm64-Installers/releases/download/1/netinstall-arm64.iso
Please note: as far as single board computers go, some will work, some will not. if they support uefi or legacy boot, they might work. Others, like the RPI, need special UEFI firmware to boot these images. Your mileage may vary, please research your device.