The officially official Devuan Forum!

You are not logged in.

#1 Re: Hardware & System Configuration » [SOLVED] [hardware] Initramfs mdadm assembly woes, udev not triggered? » 2020-09-06 13:30:27

Marjorie wrote:

Horses for courses. If a drive is rated for 70C I'd not want to load it to run at that continuously.

I fully expect any drive to be able to operate at 100% load continuously, provided it's external environmental limits are maintained.
It's over to the manufacturer to ensure that internal components don't overheat in said external environment.

The manual does not say "never write more than 100GB/hr", nor does it say "use only in LN2 cooled enclosures". It just boasts about transfer speeds, and those are mostly lies anyway.
A drive that overheats under load even when more than adequately cooled is a pile of junk, end of story. Even with a plastic case, those SSDs more than likely would have survived had crucial spent the few cents to add a thermal transfer pad.

These were in a fan-cooled aluminium drive cage, and that cage was maintaining a ~25c environment. The case of the SSD itself couldn't have been much above that.
Other drives in the same cage, including an OCZ model from 2013 and possibly the cheapest Kingston ever made, have never exceeded 35c under exactly the same workload.

I wasn't writing to them at anywhere near the fictitious "up to 500MB/s" specification either, not even 1/4 that in fact.
All I was doing was moving 100GB-ish batches of ~5MB files to the drives and moving them off again. Not "typical desktop usage", but certainly nothing I wouldn't expect any old drive to handle.

In short, it's Crucial's (complete lack of) internal thermal design that killed these, not my usage.
They're literally just a plastic box with a bare PCB rattling around inside. No screws, no heatsinking, nothing. Not even a bit of extra copper on the board for thermal mass.
I own USB3 pen drives that have thermal pads on the chips FFS.

Marjorie wrote:

Maybe I should add disk monitoring

Smartd is good for many things, temperature included.

#2 Re: Hardware & System Configuration » [SOLVED] [hardware] Initramfs mdadm assembly woes, udev not triggered? » 2020-09-06 08:44:05

brocashelm wrote:

I actually own a couple of Crucial MX500s, and they've yet to disappoint me in the two years I've been using them.

MX is the mid-range line, and I haven't heard of any problems with them either.

brocashelm wrote:

Temperature spikes have never been an issue, and it's been a pretty bad summer in my area.

This was no spike, this was pegging at 60-70c continuously, and it only took about 50GB of sustained sequential write to get there.
I probably got ~5x drive capacity of write endurance total before the first one croaked.

brocashelm wrote:

HP is a shit brand

HP make pretty decent server-grade stuff, but their consumer products are total garbage, always have been.
That said, those SSDs were almost certainly OEM jobs, and good luck figuring out who really made them.

brocashelm wrote:

I might try out a Kingston SSD next time.

I have several (including a pair being thrashed as cache drives), and I have absolutely no problems to report.
Even the DRAM-less budget models seem to be okay, if understandably slow-as molasses. And yes, even the very cheapest have metal cases and thermal pads.
Just be aware that they're one of the (several) brands known to lie about performance, if stated speeds seem too good for the price, that's exactly what they are.

#3 Re: Hardware & System Configuration » [SOLVED] [hardware] Initramfs mdadm assembly woes, udev not triggered? » 2020-09-06 01:56:33

Okay, I think we can close this one. It's hardware.

The counterpart to that failed drive was taking 27s to initialise and appear on the bus. It's certainly not ideal for the initrd to spam scary errors instead of backing off and retrying, but it's not his fault either.



[rant]
Moral of the story: The Crucial BX500 series SSDs are utter crap.

Of that pair of SSDs, one is dead as a doornail (doesn't register on the bus), the other is clearly dying.
Both are less than a year old and still under warranty, but I'll be throwing them in the trash rather than returning them - the last thing I want is more of the same.
Both have history of hitting ~70c and thermal throttling under sustained write loads, despite the enclosure and the drives directly above them never breaking 26c.
The nasty plastic casing never even gets warm, and now that I've dissected one I see somebody at crucial thinks putting a thermal pad on the controller is a luxury. 70c is listed as max operating and they never exceeded it, but I'll bet a cookie heat is why they died.

Crucial, your budget SSD line gets a solid F from me. The Kingston A400 series is not only cheaper, it's also built properly and doesn't constantly try to cook itself.
I wanted budget SSDs for that filesystem, and expected budget performance. What I didn't expect was something so shitty it can't even sustain the already mediocre performance numbers without overheating.
FWIW, a BX500 reporting 70c writes at ~7MB/s.
[/rant]

#4 Re: Hardware & System Configuration » [SOLVED] [hardware] Initramfs mdadm assembly woes, udev not triggered? » 2020-08-31 23:25:43

fsmithred wrote:

You could try adding 'sleep 1' to /etc/init.d/eudev as indicated

I could, but all this is going on in the initrd before init starts or /etc/init.d is available...

I'll do the same to the initrd script that starts udevd and see what happens, but it'll have to wait a little as I can't really take this box offline right now.
It occurs to me that there were also some hardware changes which might have fallen in the "I just noticed it" window, and those could probably be reverted temporarily.

When I get a window long enough to risk borking the boot process and reverting backups without undue screaming, I'll have another poke about.

#5 Hardware & System Configuration » [SOLVED] [hardware] Initramfs mdadm assembly woes, udev not triggered? » 2020-08-29 19:18:01

steve_v
Replies: 7

At some point recently (I not sure when, it's headless so I rarely see early boot messages), a machine of mine (beowulf) began spewing:

mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: error opening /dev/md?*: No such file or directory
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.
mdadm: No devices listed in conf file were found.

From the initrd during boot.

Curiously, the arrays appear to come up correctly, the root device (RAID1) is found and mounted, the system boots, and apart from those messages everything seems fine...

md0 : active raid1 sdl1[3] sdk1[2]               <----- /boot
      2095040 blocks super 1.2 [2/2] [UU]
     
md1 : active raid1 sdl3[3] sdk3[2]               <----- /
      105775104 blocks super 1.2 [2/2] [UU]
     
md2 : active raid1 sda[0]                            <----- Not currently mounted, pending disk replacement.
      117154240 blocks super 1.2 [2/1] [U_] 
      bitmap: 1/1 pages [4KB], 65536KB chunk


Array uuids all match as they should, I generated a new mdadm.conf and initramfs anyway, the problem persists...

Dropping into the initramfs shell with break=mount reveals something rather odd:
/proc/partitions is empty. No wonder mdadm can't find any devices.


A quick poke about in scripts/local-block/mdadm (booting with "text" on the command line reveals local-block as the source of the squealing):

#!/bin/sh

PREREQ="multipath"

prereqs()
{
        echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
        prereqs
        exit 0
        ;;
esac

. /scripts/functions

# Poor man's mdadm-last-resort@.timer
# That kicks in 2/3rds into the ROOTDELAY

if [ ! -f /run/count.mdadm.initrd ]
then
    COUNT=0

    # Unfortunately raid personalities can be registered _after_ block
    # devices have already been added, and their rules processed, try
    # triggering again.  See #830770
    udevadm trigger --action=add -s block || true
    wait_for_udev 10
else
    COUNT=$(cat /run/count.mdadm.initrd)
fi
COUNT=$((COUNT + 1))

echo $COUNT > /run/count.mdadm.initrd

# Run pure assemble command, even though we default to incremental
# assembly it is supported for users to export variables via
# param.conf such as IMSM_NO_PLATFORM.  See #830300
mdadm -q --assemble --scan --no-degraded || true

MAX=30
if [ ${ROOTDELAY:-0} -gt $MAX ]; then
    MAX=$ROOTDELAY
fi
MAX=$((MAX*2/3))

if [ "$COUNT" = "$MAX" ]
then
    # Poor man's mdadm-last-resort@.service for incremental devices
    mdadm -q --run /dev/md?*

    # And last try for all others
    mdadm -q --assemble --scan --run

    rm -f /run/count.mdadm.initrd
fi

exit 0

Sure enough, 'mdadm -q --assemble --scan --no-degraded' and 'mdadm -q --run /dev/md?*' spit out the same errors I'm seeing in a normal (for some definition of normal) boot.
Running 'udevadm trigger --action=add -s block' populates /proc/partitions, after which mdadm is happy and all is well.

I'm not particularly familiar with the initramfs scripts, but it looks to me like that command should be run before mdadm tries to scan for devices? Right?

I did try rootdelay=10, but that makes no difference, and I'm not getting anything useful from the 'net at large on this one.

Any idea what's going on here, or where I should be looking?

#6 Re: Off-topic » New here - presentation! » 2020-07-18 14:50:15

Danielsan wrote:

You sure don't use Arch? -___-

Gentoo on the desktop, Devuan on the server. I did run Arch once, long ago, it's a pain in the ass and so are many of it's users.

Danielsan wrote:

ZFS is not available on the Debian/Devuan installer and always from the Debian/Devuan installer when you create an encrypted partition you have to use LVM to write on it...

Installers are not the last word in possible configurations... Gentoo doesn't even have one.
I don't run ZFS root anywhere* though, because it not being shipped on any install/recovery media I am aware of is a headache I don't need. There's nothing preventing you from adding it in once the base system is installed though, and it's very nice.



fsmithred wrote:

It's possible to create encrypted partitions without lvm using debian installer.

I'm only a little bit surprised you don't know about this. It's not obvious or intuitive.

Of course it's possible, and TBH it looked pretty obvious to me... But then I've been doing manual partitioning since Sarge. I don't think I've ever even tried the "guided" mode.
I have deep-seated trust issues when it comes to installers, and the moment I'm presented with words like "partition" or "format"  I tend to make a beeline for the advanced option. tongue


*Except on BSD, but I don't really use BSD enough to include it here.

#7 Re: Off-topic » New here - presentation! » 2020-07-17 21:44:02

Danielsan wrote:

LVM is a great feature... I might put two disk in LVM and the third as separate mount, and encrypted, where storing all the sensible info, this seems the more rational approach to this problem, what do you think?

Sounds like as good a plan as any, if you actually intend to use the features of LVM.

To be fair I don't use it myself, so I'm not the one to ask about LVM layouts. As nice as it's features are I've never really needed them - if I want disk-spanning or redundancy I use mdraid or zfs, everything else is old-school partitions and mountpoints.
For me, LVM is one of those things that sounds really handy in theory, but is in reality a solution to a problem I don't have.

As for encryption, I have exactly 2 encrypted stores, one dataset using zfs native encryption on my home fileserver, and the /home partition on my laptop, using dm-crypt. Unsurprisingly, one is mostly used to back up the other.

The most important thing to remember about encryption, where it applies to any threat more serious than "some random stole my laptop", is this.

#8 Re: Other Issues » Devuan just froze up on reboot. » 2020-07-17 03:47:15

fsmithred wrote:

Are you sure it's not this issue?
https://dev1galaxy.org/viewtopic.php?id=1688

While it may well cause boot delays, It doesn't explain the failure to remount the root partition r/w or the thick cloud of smoke being emitted by /bin/mount in the screenshot above.
There's little point in trying to troubleshoot ifup when you can't write to the filesystem...

#9 Re: Off-topic » New here - presentation! » 2020-07-16 05:00:51

Danielsan wrote:

I am not really angry with systemd, eventually it is just a program, but with everything that surround it, I also find disheartening the lack of leadership and orientation that pervades Debian. From the leading to follow whatever the big siblings of Linux decide.

Honestly the thing that drove me away from Debian was the constant pandering to whatever overengineered crap GNOME and freedesktop/redhat was peddling on any given day.
Systemd is fine for those who want to use it, but because GNOME depends hard on it at compile-time it's been given special status in Debian... Where special means an unavoidable, unremovable, low-level please-link-everything-against-me bloat-kit.

I'd have much preferred that they simply stuck with XFCE and dumped GNOME3 from the repos until the relevant developers got over their NIH, one-true-way, ewontfix corporate nu-linux mentality. Then we could have kept our freedom to choose our low-level system tools, and those who want a good whacking with the UX-braindamage bat could just use fedora...
But that would have required balls, which apparently the Debian leadership lacks.

Debian has never been primarily a desktop distro, and railroading everyone running it on servers for the sake of leg-humping a DE project they don't want was a right slap in the face.

Devuan did the sensible thing and kept XFCE as the default desktop, because unlike certain others it doesn't try to dictate your choice of init system.


Danielsan wrote:

Hi folks,
Anyway sysv stinks hence I am thinking to use OpenRC...

I would hesitate to say stinks, but it can be a bit clunky, especially with all of Debian's mods (insserv etc) on top.
Really though, sysv is just a bit old and a bit crusty. It still does what it was meant to do, and does it tolerably well.

I haven't tried openrc on Devuan yet, but I can say it's pretty nice with Gentoo. Small, simple, cleaner configuration than sysv, and it just does what an init system should without getting in the way.
If and when Devuan ships native openrc init scripts instead of relying on sysv compatibility, it'll likely be as good as it is on Gentoo. Running openrc with sysvinit as pid1 and a bunch of sysv scripts makes no sense to me, I might as well run sysv.


Danielsan wrote:

I am still making my tests... I am still wondering if it is worth encrypt the disks for a domestic computer, even if it is a laptop. Complex scheme partitions, encryption, lvm make difficult clone your disk setup or repair your computer to recover your data if something get wrong.

I for one absolutely take the KISS approach to storage. Encrypted LVM does what it says on the tin, but it also adds a couple extra layers between you and what's on your disks - complicating, as you say, data recovery when (not if!) a drive dies.

As for full-disk encryption in general, I've never really seen the point. If I have sensitive data to protect, I'll encrypt that filesystem only and skip the overhead for the rest of the system.
TBH I really don't care if someone stealing my machine can read /usr/lib or not, it's irrelevant. Just, you know, don't store the keys to your encrypted /home or whatever on the unencrypted /.

#10 Re: Other Issues » Devuan just froze up on reboot. » 2020-07-16 04:00:25

devuanuser wrote:

Very strange.

Indeed.
Once you get in (or if you image the disk before reinstalling), it would be interesting to see the apt policy and debsums for those packages... Libraries don't change themselves (this is stable, not ceres, right?), barring some proper odd variety of disk corruption.

I'm not sure exactly what you mean by "remote dpkg install" here, but all you should need for a look around is a working mount command, the minimal live image would do nicely.

Incidentally, if that's some kind of thin terminal and you have a bunch of identical installs, you might like clonezilla's bare-metal PXEboot image restore features. It sure beats lugging HDDs around IME.

#11 Re: Other Issues » Devuan just froze up on reboot. » 2020-07-15 02:39:35

That error regarding libmount.so.1 is almost certainly the culprit, and such a library version mismatch should never happen unless a n upgrade was forcibly interrupted or one has mixed releases and/or otherwise messed about with sources.list.

You might be able to fix it by installing the correct versions of the relevant packages (mount & libmount1) from a livecd chroot, but YMMV. Depending on how the system ended up in this messed up state any number of other things may be borked as well.

#12 Re: Forum Feedback » Why Fie? » 2020-07-11 03:13:06

rolfie wrote:

I'd like to give you my reason why I would prefer the graphical installer if available: I can copy/paste passwords and encryption keys to make sure they are the same.

Well, the netinstall image doesn't include any mouse support, which I guess is a shame (but hey, it's tiny)... So some extra keystrokes and/or gratuitous use of cat might be needed.

Both the graphical and minimal live images can install the system with refractainstaller though, and they both have mouse-driven copy-paste, so there's a viable option if you run full disk encryption or something (what else?) that needs input of long strings to the installer.

#13 Re: Forum Feedback » Why Fie? » 2020-07-10 19:15:23

Tatwi wrote:
golinux wrote:

Note that this option is no longer available in Beowulf and probably beyond.

Heh, I didn't even notice! smile

Neither did I. If I need an installer I'll pick the TUI one every time, and frankly I don't understand what a GUI provides in that context besides a bigger install image and more to go wrong. Starting an X server and all the baggage that entails just to have a pretty installer nuts.

On the OP at hand:
As the patient does not belong to the tap-and-drool selfie-stick demographic, I suspect this is simply a case of classic CLI-o-phobia. For the unfamiliar, a disorder brought on when suppressed memories of CP/M, DOS, the Windows command prompt and other shells designed to torment their users are brought to light, often upon encountering a similar text-interface aesthetic years later.

For this I usually prescribe the LFS treatment, followed by a light regime of Slackware or Gentoo use. Symptoms generally resolve in short order given sufficient exposure to bash/zsh, the GNU utilities and a proper POSIX environment.

Tatwi wrote:

The Debian Ncurses installer is better laid out than the Slackware Ncurses installer, making it just a little easier to navigate, but both are fast, functional, and fine even in 2020.

Indeed. Hell, the Gentoo "installer" is perfectly fine in 2020.


GlennW wrote:

Ascii did have a nice gui installer, cut and paste options with the mouse.

Why would you need copy-paste in the installer anyway?
I mean you can use GPM at the console, but why?

#14 Re: Other Issues » php7.4-fpm has a dependency on systemd » 2020-07-10 18:19:41

rwc265 wrote:

It seems like the only thing holding it up is because they think that using a systemd tool to manage what looks like one temp file is a good idea.

Pulling in over a million lines of code to create a single directory. roll
Do we need a better example of the install-bloat and complexity-creep problems systemd creates?

rwc265 wrote:

I heard about something called opentmpfiles that might be able to manage this. All that would be needed then is a dummy systemd-tmpfiles packages to allow the Debian package to be installed, if it's truly a drop-in replacement.

As a stopgap until this is patched out in the devuan repos, you can whip up such a package with equivs and a symlink. Or just use the POC helpfully provided here.
It's quicker than patching and rebuilding php-fpm locally anyway wink

Opentmpfiles should be a drop-in, so long as systemd and the freedesktop crowd actually adhere to their own standards...


From his response to the various bug reports on this, and his and flat refusal to consider such a trivial change even when provided a patch, I guess Ondřej Surý is going on my personal "do not bother contacting, has irreconcilable attitude problems" list.
So long and thanks for all the fish, deb.sury.org. It was convenient while it lasted.

#15 Re: Desktop and Multimedia » [Solved] Virtual Box kernel modules to be rebuilt after each boot » 2020-06-27 14:29:03

PedroReina wrote:

I think that it is somehow related with the systemd issue.

Indeed it is, but that would be off topic for this thread. wink

#16 Re: Desktop and Multimedia » [Solved] Virtual Box kernel modules to be rebuilt after each boot » 2020-06-27 14:17:28

rolfie wrote:

Then tried to add to /etc/modules: the entry vboxdrv was a game changer, the error when starting my Win7 VM changed. I saw that I needed to enter also vboxnetadp and vboxnetflt, and now it works.

To be fair you shouldn't have to, something must be going wrong in the byzantine mess that is oracles init script...
The init script that I didn't see on cursory examination of the package because it's copied from /usr/lib/virtualbox by the byzantine postinst-common script, which is in turn called from another postinst script...
The init script that takes 20KB of shell to load 3 frickin modules, and clearly doesn't manage to do it reliably.
Sheesh, commercial vendors and their overengineering.

You could try debugging it, or you could just stick with those 3 lines in /etc/modules... I know which one I'd choose.

rolfie wrote:

Can't remember that I had to do this before, e.g. under Squeeze, Wheezy, or ASCII. Anyhow, I think I have got a solution now.

VirtualBox was in the repos back then (It was dropped for buster due to oracle being "uncooperative" IIRC), so presumably you were using those packages rather than the ones from oracle, no?

#17 Re: Desktop and Multimedia » [Solved] Virtual Box kernel modules to be rebuilt after each boot » 2020-06-27 07:10:17

rolfie wrote:

All the nice hints found do not fix the issue.

What hints? The very useful one that VirtualBox provides when you try to start a VM without the kernel module loaded?

rolfie wrote:

When I follow the instruction I can work with VBox

By "the instruction" you mean

modprobe vboxdrv

?

If that works then the kernel module has been built just fine, it simply needed to be loaded.

rolfie wrote:

the game starts next day when I have shut down the PC the evening before and restarted or past any reboot.

What is going on here?

Unless you have configured the system to load that module at startup (i.e. in /etc/modules or some init script), you will need to load it when you want to use it.
What's unexpected about that?

ED. The repo at

https://people.debian.org/~lucas/virtualbox-buster/

is probably a better option than Oracle's .debs. It looks like it includes virtualbox-dkms for automatic rebuilds against new kernel versions, as well as an init script to load the modules at system startup.

I don't see anything in there that would make those Debian buster packages problematic on Devuan beowulf, but as always, YMMV.

#18 Re: Hardware & System Configuration » [ SOLVED ] cant run command from commandsline » 2020-06-27 04:37:54

roluan17 wrote:

Hi Steve
...

Well that all looks fine. Rats.

Does the root account actually have a password?

#19 Re: Hardware & System Configuration » [ SOLVED ] cant run command from commandsline » 2020-06-26 10:48:18

roluan17 wrote:

I was a bit of confused that I should work from now on with "su -".

It's just another upstream solution in search of a problem. roll

'su' no longer adds /sbin and /usr/sbin to your $PATH, so you will get "command not found" for any binaries that live there.
'su -' or 'su --login' will read root's profile, so you get root's $PATH, which does include /sbin and /usr/sbin.

Stick alias su='su -' in your ~/.bash_aliases and forget about it.

roluan17 wrote:

I have no idea how to check up why I get that "ash" output.
Any suggestions?

Sounds like some cruft in root's .profile / .bashrc etc?

What does env say after you su to root, and what's in root's .bashrc, .profile, .bash_profile and .bash_aliases (if they exist)?

roluan17 wrote:

Being able as normal user to get a root-shell by just typing su "--login" without need for a password  makes me a little nervous.
Not you?

Smells like a pam screwup to me (assuming it's not some new and wonderful default).
What do /etc/pam.d/su and /etc/pam.d/su-l contain?

You should not be able to su of any kind without a password unless you are already root, or you have something like "auth       sufficient pam_<something>.so trust" in your pam su config, which would be very silly.

#20 Re: Desktop and Multimedia » Sound with Beowulf - always trouble? » 2020-06-26 09:28:29

larsH wrote:

Unfortunately allmost every gui to day are using pulseaudio, and thereby reducing latency for sound (it makes the sound worse). I know only two current gui programs that  works with alsa. Volumicon-alsa for gtk (wich I use myself) and as far as I know it qasmixer for qt.

Fortunately almost every GUI today (with the notable exception of anything related to GNOME) works just fine with plain ALSA... So long as you don't compile it against pulseaudio, which unfortunately Devuan has, and it doesn't assume pulseaudio is available because libpulse0 was installed, which unfortunately Devuan does.


LU344928 wrote:

That will probably happen eventually. We just have to be patient. The team have a lot on their plate.

EDIT: Or maybe not... https://dev1galaxy.org/viewtopic.php?id=2934

I'm going to go with "not".

Pretty much every sound-related application in the repos which can be linked to pulseaudio has been...

Because apparently upstream Debian just loves needless bloat these days, and dubious "features" like lobotomising your ability to configure your system properly by burying everything behind a GUI and a wall of XML or JSON (then adding a daemon or two and a dbus interface for good measure) is progress.

This is one of the reasons I'm not running Devuan (or any "modern" binary distro for that matter) on my desktops.
A minimal server install is still quite feasible, but as soon as you want a usable web browser or a DE, the tendency for distro maintainers to compile in everything including the kitchen sink bites you in the ass.

Devuan:
apt install <pretty much anything>
...
I see you're installing $software, would you like bloat with that? Too bad, we compiled everything we could find with '--install-lennart --enable-bloat --enforce-more-latency --everyone-uses-laptops --bug-policy=redhat'
The following 900 packages you don't need or want will be installed...

Gentoo:
USE="-pulseaudio alsa" emerge --newuse @world && emerge --depclean
...
Bask in the complete and satisfying eradication of libpulse, Firefox without nasty LD_PRELOAD hacks, XFCE with full ALSA support, etc. etc. smile

#21 Re: Desktop and Multimedia » Alternative browser for Devuan/Debian - Brave » 2020-06-26 07:29:31

blackhole wrote:

Because the primary target is average Joe and they readily suck up marketing and empty promises.

I kinda hoped most Devuan users were smarter than that. Aren't we here to get away from marketing and empty promises?

If I saw this request over on the *buntu forum I'd understand, but someone caring enough about systemd, KISS/UNIX principles and/or the redhat/corporate encroachment to be running Devuan ought to be well wary of such hype no?

blackhole wrote:

Even with Firefox, the target is windows/android/apple.

I actually have some faith in Firefox and the Mozilla foundation, if only because they're the only independent browser vendor without a glaring conflict of interest... That and Netscape/Mozilla was once the only real option on GNU/Linux.
We're not the priority, sure. But they gave us a usable modern browser back in ~2002, and it's still all that.

#22 Re: Forum Feedback » Devuan » 2020-06-26 02:00:21

sumbodee wrote:

We're obviously never going to agree.

We certainly won't if your only interaction with this community is to drop in and say "Devuan is too hard, I'm going to use Mint."

Feel free to use whatever distro you want. If no-reading one-click installs are your thing, Devuan probably isn't for you.

If you have questions about Devuan, we're happy to provide answers.
If you have a problem to solve, we'll probably enjoy helping you.
If you have constructive ideas on how to make Devuan better (ideally with some code to share), we'll gladly discuss them.

If you're just here to (passive aggressively) complain and make pointless comparisons to $newb_friendly_distro though, I'm pretty sure this conversation is over.

#23 Re: Desktop and Multimedia » Alternative browser for Devuan/Debian - Brave » 2020-06-26 01:46:44

LU344928 wrote:

Perhaps I'm missing something but if you don't opt in to those schemes then it seems to me there's not a lot of difference to Firefox etc.

Indeed. AFAICT it's nothing more exciting than YACB (Yet Another Chromium Build). So why all the yammering about it, like it's the hottest new thing?

#24 Re: Desktop and Multimedia » Alternative browser for Devuan/Debian - Brave » 2020-06-25 00:08:17

What is with all the noise about this "brave" browser recently anyway? Is it demonstrably better than Firefox/Iceweasel or a degoogled chromium build?
Personally I'd be highly suspicious of a new browser that is advertised as heavily as this one appears to be...

Head_on_a_Stick wrote:

Interesting article about Brave linked on lobste.rs:
https://practicaltypography.com/the-cow … brave.html

Ed. Yup, that's pretty much what I expected. "Have our ads and tracking instead of theirs". Free cryptocurrency woo and virtue signalling included.
No thanks, I'll stick to my adblockers and javascript defangers.

#25 Re: Forum Feedback » Devuan » 2020-06-24 23:50:01

sumbodee wrote:

Double click install.
Oh dear, this is much too complicated for me.

The Devuan installer is almost identical to the Debian installer, which is thouroghly documented and has served well for many years.

Comparing Devuan to Mint/Ubuntu is disingenuous, they have very different intended audiences.
One focuses on being beginner friendly, the other on flexibility and reliability. This is why they have an easy-mode installer, while ours has lots of options. Making the install process like Ubuntu would exclude a large number of possible configurations.

If the flexible and configurable installer is "too complicated" for you, perhaps you should read the manual?
If that doesn't answer your questions, there's always the Debian install guide, which is 99% applicable to Devuan.

sumbodee wrote:

I'm not a newcomer having started out with Ubuntu 6.06

If Ubuntu/Mint is all you have used since then, you're still a "newcomer" to Devuan.
Both of those distros are noob-friendly Debian derivatives targeted squarely at those who are allergic to the command-line, and they exist almost entirely to make Debian (and thus Devuan) less complicated.

Board footer

Forum Software