Re: [DNG] Devuan with usr merge?
On Tue, 2021-11-09 at 01:56 -0500, Steve Litt wrote: > > The logic is still the same. I need a guaranteed place on the root > partition to find the programs necessary to mount all the other > partitions, or else I'll need to run an initramfs. Been following this debate. Admit that a few years ago I'd have reflexively said keep /bin and /sbin but now? The assumptions have changed so much it no longer makes much sense. The size of the OS is just so small now, compared to storage media and data files. Even a small SSD will easily hold all of /usr for all but the most bloated installs on old obsolete storage media. So simply including /usr in the root filesystem makes sense for almost all use cases. On the other hand, putting everything in /usr makes some interesting options possible, like making it a read only mount point except during updates. Back in olden days being able to reliably boot into a minimal environment for rescue and recovery was important. Now a rescue distribution on a USB stick is far more effective when things go wrong. So yes, it is time to eliminate /bin, /sbin and /lib. Wish I could say the same thing about the X11 vs Wayland divide. See the cold logic and theory in the Wayland argument but keep looking at the current reality and Wayland comes up short. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FSF, RMS and a danger to almost all GPL code
On Sat, 2021-03-27 at 08:30 -0400, Steve Litt wrote: > And now you're suggesting Devuan put that all at risk to take a stand > on RMS. Well you know what? No distro should get involved with > politics, and this RMS thing *is* politics. It cost Mint plenty of > users when they said supporters of Israel shouldn't use Mint, and it > just might destroy Devuan if they take a stand, on either side, on > this RMS thing. Something struck me as deeply wrong about your post but I couldn't articulate it. After much pondering it struck like a bolt and it was the paragraph above that did it so thanks. :) The RMS thing is politics, that is why they want him gone, he won't inject politics into the the FSF. And we must fight because we are all in extreme danger. Apparently we all just assumed Richard Stallman was immortal and would always lead the FSF or we wouldn't have done what we all did. We must save Richard's bacon long enough for everyone to fix the problem. Hang on for a brief diversion, the tale will get back on track. CoCs. They are annoying but can't impact usage. They can't be avoided in most projects now because too many developers work for corporations and would be fired for failure to demand them. Because Free Software licenses don't allow restrictions on field of use, they don't impact users at all. If enough productive developers decided they didn't like the CoC they could easily smash it with a Libreoffice gambit. One way gate. Fork a new project site under a new name with a one line CoC sayin "The only code of conduct is be excellent and never propose editing this file, it is the only mandatory banning offense." The new fork can take every patch from the original but the original can't touch the new site lest they accept code from people who haven't agreed to the standard pozzed CoC. Checkmate, the second a critical mass of independent developers decide to go for it. Now imagine Stallman is out at the FSF and somebody tries this. All they need do is release the GPL4, allowing CoCs, field of use restrictions and all the rest of the political nonsense be integrated into the actual license, impacting developers AND users. It was your mentioning Mint's misguided (and certainly unenforcable) attempt to impose field of use restrictions on their users that got the thought train going. It is vital that as many projects as possible get to work NOW to change their license terms. Corporate dominated projects are probably already past the point where they can be saved. Be prepared to grab the last available version under a sane license when the time comes, and as events are moving ever faster, it will come soon. As of now there are only three possibilities that are survivable. GPL2, GPL3 and GPL2 or GPL3 at your option. No "or later" ever again. BSD code of course has no defense when the corporate HR depts come calling with demands. Nothing to be done about that. Haven't had time to look at the other licenses. Anything with an "or later" clause, be warned and pay attention to who you are giving unilateral authority to rewrite the license to. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FSF and human rights
On Fri, 2021-03-26 at 15:46 -0400, Steve Litt wrote: > > I'd suggest nobody sign anything, and nobody respond to this email. > > If you believe that Stallman was removed, shunned and criticized > because of guilt by association, then it's not much of a stretch to > believe that you will suffer the same fate if you defend him. And then > any who defends *you* will suffer the same fate, ad infinitum. This exactly how a "climate of fear" works. Anyone who has looked three seconds at the Cultural Revolution or any of the other descents into madness of the 20th Century knows exactly what is going on here. Time to sack up people. If we can't find the will to defend RICHARD F*CKING STALLMAN, we won't defend anyone. One by one we will all be singled out for destruction. This attitude above sounds like the mewling sounds Republicans have made for decades, ever retreating because it is never "the hill to die on" as the revolution marches over their former "inviolate" position and National Review reverses course and assigns someone to pen "The Conservative case for X." This isn't actually about RMS, it is just the usual SJWs marching ever onward, seizing resources and key nodes in the social order. The FSF is the prize they seek, both to loot it and because it is a choke point to take and hold. Same reason they seized Debian. Ever wondered why Debian went from a model of enlightenment and civility to what it is now? It wasn't systemd, that was a symptom. It was infiltrated and seized by intolerant people who cared nothing for Debian or its culture, it was just another resource to seize as they moved through the software world, killing it and wearing its skin, then demanding respect due the original entity. They don't even care about RMS, he is just in their way. He won't repurpose the FSF into another culture war battlement, he will insist it remain focused on its original goal of software freedom. So he will be driven out. Apparently they won't even have to expend much effort because everyone is already too terrified to even say his name. RICHARD M. STALLMAN IS A GOOD MAN WHO HAS DONE MORE FOR CIVILIZATION THAN ALL OF HIS DETRACTORS COMBINED. FLAWS INCLUDED. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] history
On Fri, 2020-08-07 at 22:21 +0200, d...@d404.nl wrote: > > It is indeed off topic so i will keep it short: show me a philosophy > of > life or religion which has not been abused by a power hungry > totalitarian dictator or political system. Been at it for a Century now, find ONE attempt you would like to hold up as a success. The best so far is stagnation, general despair and slow dissolution, the all too typical case is body counts that Hitler would be appalled by. Yet for some reason Hitler is the absolute unit standard of Evil while Stalin, Mao, Pol Pot, etc. get a pass because "they meant well." No, time to make being a socialist / communist as disreputable as being a goosestepping Nazi larper because they are at least as dangerous. Yes, every system eventually fails because we still haven't solved the "Government" problem. But the others have successes to point to. Republics have many successes in the past, even if America is fading fast. Parliamentary systems have successes, there were centuries where being born in England was winning the lottery. Even full Monarchy has examples of peace, prosperity and good times. Imperial Rome would have been a great place to be in its good time. Lots of spots on China's timeline where it wouldn't have sucked to be alive. It would be like if Lennart and his descendants had been banging away for a Century and their stuff still sucked, but large numbers of hackers and big money still supported their project. Meanwhile sane people were like "Bruh! Thought about tossing the premise and trying something different?" Or like people who still run Windows after decades of failure and breathtaking security flaws, but they just know the next release is going to be stable and secure. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] history
On Fri, 2020-08-07 at 09:53 +0300, Dimitris via Dng wrote: > On 8/7/20 12:36 AM, marc wrote: > > People being easily identified and > > tracked in real life is something that strengthens authoritarian > > regimes > > (whether fascist or communist) as well coercive corporate > > interests. > > there were no communist authoritarian regimes in history.. communist > by > name perhaps, but in reality, authoritarian = fascist.. Oh, how original. The "real Communism has never been tried" defense. How many have now tried it and got exactly the same end result? Just how many more bodies need to lie in shallow mass graves before you give up on your beautiful theory? I know it is offtopic but this needs to be called out each and every time, lest another hundred million (or more) die. Whether stupid or knowingly evil doesn't matter, these people will get us all killed if they aren't firmly put down. Especially relevant since most of the Western World is in the grip of Color Revolutions at the moment. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Deleted qemu image
On Thu, 2020-07-16 at 11:35 +0100, fraser kendall wrote:
> I have just done the stupidest thing. I was freeing up (rm -rf) space
> on what I thought was a storage directory (/srv), but I have now just
> discovered that it contained a critical qemu image. The image is a W7
> VM and is still running; it appears unaffected. The /srv partition
> is the largest on this machine and the testdisk recovery image of this
> partition (~170G) is too large to fit anywhere on the hard drive.
>
> This machine is mission critical. I cannot take it offline for
> another
> 6 hours, and I'll need to have it back up asap, (within an hour) so I
> need to plan my attack.
>
> So some very naive questions.
>
> Best option: 1) can I retrieve the deleted qcow image from a running
> instance of that image?
Yes. Find the process ID of the Qemu job and look in
/proc/${QEMUPID}/fd for the file handle showing it is connected to the
deleted image. Use cat to dump that handle to a file somewhere safe.
It will be an image of a running machine so you will need to run chkdsk
on it, but it should be similar to a power glitch and easily repaired,
especially if you quiet down activity in the VM before you take the
copy.
Once you have that you can try advanced things like pausing the VM and
see if qemu holds the file open. There are probably tools that will
create a file pointing to a given inode so you might be able to just
regenerate it.
> Fall back option: 2) does anyone know if a new installation of the
> (Dell) W7 iso will still activate now that W7 is EOL?
>
> I know that option 2 (writing to disk) will reduce the possibility of
> a
> testdisk recovery. So, here's Q3: can i squeeze the second W7 VM into
> a
> 6G qcow image (remaining free space in /home)?
>
> I'm not going to do anything for a while, except think. And hide from
> the boss. All help would be appreciated.
>
signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] A way of holding telephone-conferences with DEVUAN?
On Wed, 2020-04-08 at 14:07 -0700, spiralofhope wrote: > As an aside, gab.com has been working on its own alternative, but they > haven't released any details (or source code) and I wouldn't be > surprised if it became a paid service for significant use. They have already said it will be a paid service for heavier users. Everybody charges for this stuff beyond a few users, it ain't cheap to host. But Gab has finally got the Open Source religion so we can expect a code drop for a working video conference system that is fully browser based on all major platforms since they can't have an app, they are deplatformed everywhere, even on f-droid. Adversity inspires innovation. They have their own fork of Brave for a browser so expect the initial target to be the Chromium family tree. Once server code drops somebody has to figure out how many oddball dependencies it has and get a package upstream into Debian. If every organization could host video conferences internally, and without it being yet another "dangit, gotta dual boot Windoze to talk to people" situation, it would be a game changer. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Solving simple problems in amazingly complicated ways
On Thu, 2020-03-12 at 21:45 +, Rainer Weikusat via Dng wrote: > - the sole purpose of this text is for the amusement of people who > ever > had to find a (preferably simple) solution for a complicated problem > - > > Problem I had to deal with since yesterday: Some Debian 10 system (use > of systemd mandated) installation I've created was to be captured by a > certain image capturing tool running on Windows. As it turned out to > be, > this capturing tool has no support for Linux swap partitions and thus, > tries to capture them by doing a sector-by-sectory copy of random junk > which won't ever be of any use again. > > Proposed solution: Turn that into an ext4 filesystem, record the UUID, > run a script at boot to convert it back to a swap partition. This > could > have been solved by suitable manipulation of /etc/rcS-symlinks but the > mere thought of something as unsophisticated at that would cause > systemd > developers to start spinning until the reach escape velocity, never to > be seen again - and who could possibly want that. How about a simpler solution? On shutdown: 1. Capture the label and UUID of the swap partition. 2. Do a swapoff. 3. Zero out the swap partition. 4. Remake it with the same label and UUID. It will still get a sector by sector copy but assuming it is compressed it will be of trivial size. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can even possibly go wrong?
On Thu, 2020-03-12 at 20:21 +, Simon Hobson wrote:
> Dan Purgert wrote:
>
> > It's certainly useful in a "campus" environment, where you're quite
> > likely at a different computer all the time (i.e. grabbing whatever
> > is
> > free in the computer lab to print your final paper).
>
> Isn't the answer there to mount your home dir off it's server on
> whatever machine you are using ? Something perfectly doable since ...
> err ... long before I ever got involved with any unix[like] system.
Yeah, we have had NFS homes here for literally decades. It is great.
Here at a small rural public library we run a split network for staff
and patrons. Both have an NFS server and mount /home/${USER} from it.
All are imaged from one master so updates are also automatic. Anyone
can log onto any machine on the same side of the network and it just
works. If a machine fails we throw a spare on the desk and it just
works.
So of course it has to be reimagined.
signature.asc
Description: This is a digitally signed message part
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What can even possibly go wrong?
On Thu, 2020-03-12 at 11:14 +, Rowland penny via Dng wrote: > > Here we go again, reinventing the wheel ;-) > > Windows has something similar, they call it roaming profiles and that > has its problems. It isn't exactly reinventing the wheel, it is more like porting the wheel. The fact Windows has a similar feature is exactly the point, it has always been the point. RedHat/IBM is working with Microsoft to prepare the way for what anyone paying attention knows is coming. Maintaining the Windows kernel and device drivers is inefficient and is gaining them nothing at this point. So make Linux + userland feature complete enough to simply port the Windows UI to it and merge it into one new platform. If they could bolt Win32 onto NT they can bolt it onto Linux + Systemd + Wayland + *kit + yet more RH cruft to make it all work. The sooner we realize that RedHat is leading nothing less than a hard fork of Linux + GNU into Linux + Windows, exactly like Google created Linux + Android btw, the less damage to the Linux + GNU/UNIX side of the fork. It is long past the point where we need to move our tree away from RedHat and everything it has infected. If that means adopting large parts of modern BSD, so be it. Guess that depends on whether there is anyone left at GNU who can make strategic decisions and just how many "GNU" projects are effectively RedHat ones now. Stallman being #meetoo purged was probably an intentional thing. Once we finally complete the fork everyone will be happier, the world will be a better place, etc. Window atop Linux will even be a better product. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Insane defaults on Raspberry Pi images - How to fix corruption/dataloss
On Thu, 2019-11-14 at 22:03 -0500, Steve Litt wrote: > The piece of information I couldn't find in your (John Morris') data > is > how much of the 160GiB is consumed with data. It makes a big > difference. They have had most of their space written to at this point. The setup is three physical machines that host two virtual machines (web frontend and a postgresql database) running by themselves on two of them and another pair of development VMs on the third or the third is powered down as a spare. The VMs rotate between the three physical hosts on every upgrade cycle to spread the wear on drives and the servers. The production images are about 32GB, between 50% and 80% utilized currently, but the remainder of the drives are unused, but dirty, between moves. Can't use fstrim in the VMs because qemu / libvirt doesn't support it yet. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Insane defaults on Raspberry Pi images - How to fix corruption/dataloss
On Wed, 2019-11-13 at 04:06 -0800, Bruce Ferrell wrote: > Well, I was thinking more along the lines of the "early" failure rate > for SSD and not so much the convenience of a thing as small as my baby > finger nail with insane amounts of > storage. I have active and still in use rotational media from the > 90's. SSD just can't do that and flash... We don't need to go into > it. That's what started this thread. There is a big difference between SD cards, USB sticks and real SSDs too. And there is another big difference between consumer SSD and Enterprise gear. Here is some real world data. Drive has been in pretty much constant use in production at a public library running the online catalog and in house cataloging / automation / etc. since 2011. === START OF INFORMATION SECTION === Model Family: Intel X25-M SSD Device Model: INTEL SSDSA2M160G2GN Serial Number:CVPO0510036E160AGN Firmware Version: 2CV102HD User Capacity:160,041,885,696 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 1 Local Time is:Thu Nov 14 15:09:55 2019 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 3 Spin_Up_Time0x0020 100 100 000Old_age Offline - 0 4 Start_Stop_Count0x0030 100 100 000Old_age Offline - 0 5 Reallocated_Sector_Ct 0x0032 100 100 000Old_age Always - 21 9 Power_On_Hours 0x0032 100 100 000Old_age Always - 71816 12 Power_Cycle_Count 0x0032 100 100 000Old_age Always - 148 192 Power-Off_Retract_Count 0x0032 100 100 000Old_age Always - 101 225 Host_Writes_Count 0x0030 200 200 000Old_age Offline - 414459 226 Load-in_Time0x0032 100 100 000Old_age Always - 184 227 Torq-amp_Count 0x0032 100 100 000Old_age Always - 0 228 Power-off_Retract_Count 0x0032 100 100 000Old_age Always - 3027407118 232 Available_Reservd_Space 0x0033 099 099 010Pre-fail Always - 0 233 Media_Wearout_Indicator 0x0032 096 096 000Old_age Always - 0 184 End-to-End_Error0x0033 100 100 099Pre-fail Always - 0 SMART Error Log Version: 1 No Errors Logged So yeah I trust SSDs now in production workloads. It is in a RAID1 though so trust but verify is still the watchword. There are six of these drives in the three servers making up our Evergreen install, all bought at the same time and all still going strong. Unless something unusual happens they are more likely to be taken out of service for being too small than becoming unreliable. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] semantic of sizeof operator in C (was: simple-netaid from scratch)
On Wed, 2019-06-12 at 08:40 -0400, Hendrik Boom wrote: > > More precisely, sizeof(foo) is the spacing of consecutive elements of > type foo. Most importantly for most people, malloc(sizeof(foo)*n) must not cause unexpected things like a kaboom. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] MATE 1.22
On Mon, 2019-04-15 at 22:37 +, Antonio Volpicelli via Dng wrote: > Hi devuaners, > > the version of MATE desktop 1.22 is available on hezeh (remember is > experimental) > Not having any luck. I finally bit the bullet and went up from Jessie to ASCII. On Jessie I rebuilt the three packages mentioned somewhere in a wiki with the trivial patches (mate-session-manager, mate-power- manager and mate-applets) and everything was wonderful. Updated and of course no power management again. Tried the one in backports figuring at least that should work by now. Nope. Googled and found your mate repo. Tried it straight and no joy. Have even tried mixing and matching a bit. So far, nope. Running slim for a desktop manager, have upower running and consolekit. Currently have zero backport mate packages and as many of yours as made sense (didn't really want all of the MATE oddities). Any idea where to start looking? Power management itself still works, running pm-suspend as root puts the laptop to sleep. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
On Tue, 2019-04-02 at 09:21 +0200, marc...@welz.org.za wrote: > Weirdly enough I trust devuan a bit more after this incident: Yup, same here. A good prank on Apr 1 is perfectly in keeping with the finest UNIX traditions. It is the humorless scolds who should be suspected. Seeing the poo flinging on this mailing list over a April Fool gag reminded of the Fedora code name antics in the "Beefy Miracle" incident that eventually ended the whole release code names entirely. Useless snowflakes that "just couldn't even!" kept squalling until the corporate types stepped in and ended the game. Yes this is serious work but it also has to be fun or people aren't going to want to do it. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mozilla is at it again - Firefox nightly sends all your hostname lookups to cloudflare
On Wed, 2018-03-28 at 02:42 +0200, Adam Borowski wrote: > More interesting is the timing between this addition and the DNC hack, where > the files are known to have been saved to an USB pen drive. This would > explain the weird inclusion of refer[r]er, which has no obvious legitimate > use but would often leak who downloaded the file (if a session was > identified as an argument to the URL rather than a cookie). Looks older: https://bugs.chromium.org/p/chromium/issues/detail?id=45903 So if Seth Rich used Chrome, it might have incriminated him. If someone got the physical flash drive he was using. Or he uploaded a .tar file that preserved the extended attributes? But the 4chan spergs who went over the DNC Leaks would have noticed something that big. And it gets better: https://www.freedesktop.org/wiki/CommonExtendedAttributes/ I swear, these people are a menace. According to the same madmen who gave us the modern desktops this isn't a security problem, a privacy violation or even a bug. It is a feature. According to that bug, this started on Mac and was added to the Linux version. No note saying it was added to Windows. If anyone still runs that legacy security nightmare, it would be good to know if it has or doesn't have this anti-feature. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Is the removal of powermgmt-base from apts' suggested packages a problem for us?
On Wed, 2018-02-28 at 00:03 -0500, taii...@gmx.com wrote: The first part of your post is correct. But in the interest of avoiding misinformation I gotta correct the record on this paragraph. > SystemD systems take minutes to boot even without the bogus "start/stop > job running for *thing*" whereas devuan takes 15 seconds, it isn't > better in any way but the so called experts of the world clamor for it > and insist your thoughts on the matter don't matter - the same people > who think that a non-owner controlled MS "secure" boot is just fine > because oh hey a MS signed grub comes with RHEL. SystemD only takes unusual time to boot if something is wrong. For example I had a misbehaving USB memory card reader that stalled. Otherwise Fedora boots faster than the machine POSTs. Of course my other machine (a slower laptop) running Devuan also boots faster than it POSTs. The big reason we were pitched systemd stopped mattering about the time everyone moved to booting from ssd. But of course, as you noted, that wasn't the reason at all. Second, Microsoft is actually doing the industry a favor by hosting the signing authority for UEFI. Windows doesn't even sign with those keys, system makers preload an entirely different one for Windows. Others were offered an opportunity to step up and be the official UEFI signing authority, including leading entities in the FOSS world; they all looked at the effort and expense and declined the honor. While we should always be wary where Microsoft, Google or Apple are involved in a piece of critical infrastructure, to date they have played it straight and signed boot loaders for everyone who wants to play the secure boot game. Considering the effort to support secure boot for a distribution, the $100 fee is not a serious burden. Also keep in mind that motherboards properly implementing the secure boot spec do permit changing out the keys, it is just enough hassle that distros, probably rightly, believe that if they don't just get signed by the preloaded keys few would ever use secure mode. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
On Mon, 2017-10-23 at 17:06 +0200, Didier Kryn wrote: > I've read previously on this list that secureboot doesn't prevent > booting from a usb key... Or did I misunderstood? Correct, so long as the boot loader on the USB key is signed by a key the system trusts. And you didn't disable booting from USB in the BIOS and slap a password on it to stop people from messing with it. All the basics of locking down a machine for an environment where people might mess with it. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
On Tue, 2017-10-24 at 09:01 +0200, marc wrote: > Secureboot is designed for them, not for you. You might come > up with a really exotic use case, where it might help you. But > if you look at it carefully enough, it relies on secureboot > redefining root to something weaker than what we want, and > running some complex infrastructure which you are unaware > of behind it. If you want a weak root, run a virtual machine > instead. Not at all. Right now if you install Fedora or Ubuntu you get the protection of secure boot. You already trust them if you are installing their OS, correct? Everyone signs the kernel package at the package manager stage so we can all use untrusted mirrors. So now they also put a signature on a grub-efi package with a key signed by the UEFI CA that embeds their company keys. Now your system validates that GRUB is clean and it checks the kernel hasn't been tampered with before executing either of them, Eventually Debian will begin shipping signed grub-efi and kernel packages. Devuan would have to pay $100 to get a signed grub-efi of its own (with a Devuan kernel signing key embedded) to ship kernels built by them if they don't just pass on the Debian grub and kernel packages unmodified. That is it, one can argue how much security benefit it brings but it is non-zero and requires minimal effort to achieve. I think you have to pay again if your grub-efi package changes but it doesn't seem to churn much. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1
On Tue, 2017-10-10 at 01:49 +0200, Alessandro Selli wrote: > By the manual, the correct solution in configuring Grub as to pass the > kernel these parameters: > > biosdevname=0 net.ifnames=0 Those fix similar problems but not exactly the same ones. The udev persistent rules get you when you move an image from one machine to another or swap out failed hardware and suddenly you have no network because eth0 suddenly became eth1. And as I noted, not only network device names but CD drives as well are impacted. The fixes you suggest solve the equally annoying problem of eth0 or wlan0 unexpectedly turning into a string of gibberish after an upgrade. They are turning everything into a UUID or similar string of untypable gibberish. It is almost like they don't want you to use the command line directly anymore. Nah, that couldn't be it, right? signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd-udevd: renamed network interface eth0 to eth1
On Sat, 2017-10-07 at 10:06 -0300, Renaud (Ron) OLGIATI wrote: > On Sat, 7 Oct 2017 13:51:02 +0100 > Simon Hobson wrote: > > > The topic was discussed to death not long ago and the consensus seemed to > > be that "there is no solution that works for everyone" ! As Jochen says, > > for "simple" machines with no more than one ethernet and one wifi, nothing > > needs to be done. For everything else then there is a problem that needs > > solving. > > > > I think the only thing we did all agree on was that systemd's latest screw > > around with device names was the worst option of all ! > > What about the possibility of having somewhere a config option: > "Do you want fixed NIC names or do you want them renamed whenever > changed/moved ?" > There is. Make /etc/udev/rules.d/70-persistent-net.rules a symlink to /dev/null and it will leave you alone. Do another for 70-persistent-cd.rules if you have a laptop and have external burners at home and work. On the other hand, udev rules can also be mighty handy for making sure USB-Serial adapters, android devices, USB sticks, etc. show up at consistent locations when that is what you want. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Gnome?
On Tue, 2017-09-26 at 03:42 -0400, taii...@gmx.com wrote: > Why not use the gnome 2 fork MATE? Why not? It mostly works out of the box, I'm using it now. If you install it onto a laptop you won't have working power management because of dependencies on systemd. Google can give you the details but you need to locally rebuild mate-applets, mate-power-manager and mate-session-manager, some with no changes some with one liners. Slept since I did it and can't remember details at the moment. :) Once you fix those three pakages, no problems. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] librezilla: [WAS: Has anyone tried waterfox?]
On Thu, 2017-09-21 at 18:12 +0200, Edward Bartolo wrote: > Excuse me for interrupting this conversation, but, what is the point > of making sure a browser is secure knowing there is a complete HIDDEN > OS running all the time? I have no idea what it does and what > functions it offers to the outside world. To learn about such > functions I must either believe Intel or accept what reverse engineers > found. The fact that even GNU/Linux cannot get rid of such an OS is > depleting me of motivation to seek a more secure system. For me, it is > becoming enough if I can use a computer and be cautious if I do not > want to disclose sensitive/private information. You aren't the only one worried. Go look at the new Dell Latitude 14 Rugged and notice something interesting. Intel vPro ME Inoperable, Custom Order +21.00 Not seeing it on any others yet, but enough people are asking that they are offering the option. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New Devuan-based distro
On Thu, 2017-08-03 at 03:31 -0400, Steve Litt wrote: > On Wed, 2 Aug 2017 10:36:50 -0300 > > > > EterTICs GNU/Linux is a GNU/Linux distribution aimed for community > > radios of Latinamerica. His goal is to be 100% libre and it has all > > the software needed to setup a "libre" radio including Radit, > > Guarangoradio, Rivendell, Audacity, Ardour and Cadence. > > > I couldn't read the web page ,but if this references software defined > radio, you know, where you use an A/D converter as a tuner and control > it with software, I'm really interested. Nah, they are building radio station automation systems. Also a very interesting thing, but farther up the stack from the raw modulation / demodulation / tuning SDR is about. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] MikeeUSA
At the risk of lowering the signal to noise on this list even more, I'd like to note that about seven minutes before this new nym posted here it posted the same text to the Fedora users list. There was exactly one reply. I won't spoil it, go look it up because it worked. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Desktop-Environment] Cinnamon and MATE
On Fri, 2017-07-21 at 16:25 -0500, Don Wright wrote: > Dragan FOSS wrote: > >I think it's best to drop 32-bit support at all... it's such a waste of > >time and resources. > > > As long as you're pruning, kill x64 as well, because the majority of > computers sold are using ARM architecture and run Android or iOS. I think you are joking, but it helps not to confuse the three big forks 1. Linux / GNU / X, this is the fork Devuan is on and few Devuan installs are on ARM. At this late date, there probably aren't many on x86_32 either. Which is why discussion of eliminating a big chunk or archive space and compile time will continue to recur until eventually nobody can muster a good argument for continuing. 2. Linux / Android, that is what is on most "smart" phones, "smart" TVs, tablets, etc. 3. Linux / RedHat, SystemD and the rest of RedHat OS, found on too many former LGX distros. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] some ASCII issues
On Sat, 2017-06-24 at 11:08 +0200, Didier Kryn wrote: > Anyway I think there's a simple method to live without the > initramfs. Everything which is done from initramfs could be done the > same way from a disk partition, which might make it easier to debug: > have a /os directory containing all the necessary subdirs, /os/proc, > /os/sys, /os/dev, /os/run /os/usr, /os/lib, /os/var, /os/home... , mount > the first five, create the few necessary files and symlinks and > switch_root() to /os. This is exactly what your initramfs does. Nope, that negates one of the principle reasons to use an initramfs in the first place. You assume the stock kernel can see the drive where you intend to put this new partition; one of the big drivers of initrd in the first place was exotic hardware, etc. so GRUB uses BIOS (including extension ROMs on controller cards) to load both the kernel and the initrd so it can take whatever steps are needed, i.e load the right modules, start lvm, setup encrypted filesystem magic, etc. to make the main drive/partitions/etc. visible. Your idea could deal with most everything that didn't need a kernel module but totally fails at that task. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] some ASCII issues
On Sat, 2017-06-24 at 11:04 -0500, Don Wright wrote: > Just teleport into the datacenter on the other side of the planet, or the > office building where your after-hours key card doesn't work because all > cards were cancelled following the alleged burglary last week*, or do some > other Herculean task, and insert that healing potion. One acronym. IPMI. When it is truly important, use real server hardware designed to be remotely managed. In a worst case scenario like you describe you might need a Windows PC on your end to use the full featured vendor supplied IPMI client tools that let you remote mount a USB stick or CD to a machine but it can do it. Of course now they are pushing the almost entirely closed Intel AMT stuff. Bleh. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] some ASCII issues
On Fri, 2017-06-23 at 16:41 +0200, Antony Stone wrote: > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if > you want to start feeling annoyed as well as surprised. Dunno, that one actually makes a lot of sense. Applying the logic of Chesterton's Fence here seems sound. They did their homework in researching the original reason for the tradition, carefully examined the question of whether those reasons still apply and the consequences of the change. The original reason no longer applies, we should all agree on that point, right? We don't NEED to install on a small volume and then mount the large stuff on a different media, even when we install /usr on a different filesystem it is almost always a partition on the same physical device. So then we only have the question of whether it is best to put everything down /usr or eliminate it. The arguments they advance for snapshotting, using a read-only mount or network share of pretty much the entire non-host specific portion of the OS is a pretty good reason to pick putting everything down /usr. Counterarguments are few. If you don't want to use an initrd, just avoid making /usr a mountpoint. As for rescue, in the before time when the /usr split occurred, cheap live CD/USB stick rescue media was not an option. It is now. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] default signing Re: [ann] heads 0.0 is out!
On Fri, 2017-03-03 at 10:09 -0500, Hendrik Boom wrote: > What default cryptographic identity would it use? > > -- hendrik My notion is an email client should look for a keyring and if it can't find one it should default to creating a basic key and publishing it to one or more keyservers. Imagine if every message from $foobar mail client always had a signature attached. Now imagine that it also attached the public key on 1-1 emails. Just that would raise awareness of signed and encrypted email, creating a demand for other clients to chase the feature. Now harvest any keys it gets by that method or by looking up in the keyservers. Then instead of just signing it can start signing and encrypting by default once it has a key for the receiver. Once all clients had adopted the feature most personal email would be encrypted by default, combined with the current trend toward mail servers encrypting traffic between themselves you get a lot of virtually untrackable traffic that would give the NSA fits. No, normies with keys generated by default and no care put into protecting it would not be as secure as hard core types with their key material on external devices. But it would improve general security greatly at almost no expense. Here is the kicker. It is an obvious idea yet exactly zero mail clients have ever did it. Not the big commercial ones like Outlook, Lotus Notes or Eudora, not the big free ones like Thunderbird or Evolution. Not even Pine or GNU's Emacs Mail. Zero is a magic number, when you see zero or infinity you always take another look at your figures to see if you made a mistake. Well here is a suspicious zero. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Studying C as told. (For help)
On Fri, 2016-06-24 at 15:11 -0400, Steve Litt wrote: > Stuff like this is the reason I soon abandoned K&R as a learning > tool, > and used it only to determine the official behavior of C. > > Bit stuffing, sliding and masking were a tool of the assembly > programmer > back when your RAM could be counted in four digits and your processor > had little power. Or you are doing the sort of things most C code written these days does. My last C program was taking to an RFID writer over a serial port to implement ISO 28560 standard library article tags. Bit fiddling is useful when the storage available on a typical RFID tag is less than a tweet. The graphical interface was in Tcl/Tk, because that sort of thing doesn't leverage the strengths of C. But trying to do the bit fiddling parts in Tcl would have been the exact opposite of fun. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to acknowledge ported version of Open Source program?
On Tue, 2016-06-07 at 14:35 +0200, Arnt Karlsen wrote: > ..11 years with Groklaw.net has thaught me to be a little harsher; > you cannot "port" a program written under one license (MIT), under > another license, unless that first license has language that allows > such "relicensing" under other licensing terms. MIT is permissive. It can be relicensed into GPL fairly easily, much like LibreOffice took the similar Apache licensed OpenOffice into the CopyLeft. It made for a one way gate, new code added to OpenOffice could still freely move to LibreOffice while innovation occurring on the LibreOffice tree could not go back to OpenOffice. OpenOffice is now pretty much a moribund project. It isn't the friendliest move, but it can be done. I'd suggest Mr. Chung study the license files in the LibreOffice package. But first try for a peaceful arrangement with the original author; just because something is legal doesn't mean it is the recommended action. If there is ever to be a hope of cooperating with the original author both efforts need to be using a license you can both live with. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Pi hole
On Sat, 2016-05-21 at 16:43 +0200, Adam Borowski wrote: > Yay curl|bash. I'd say recommending such a command as their > installation > method means their view on security is so bad that no one should > touch them > with a $LENGTH pole. At least as safe as a package, both are taking executable content from a source you don't implicitly trust and running it as root. (The install video shows a normal user but it assumes that user can run sudo. Look at the source.) Now if it were a http url there would at least be an argument about Man in the Middle threat, but it is an https. All they are doing is making a single cut/paste job to install instead of a list of command most newbs will screw up and then flood the forums about. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Supervision scripts (was Re: OpenRC and Devuan)
On Wed, 2016-05-04 at 21:41 +0100, Arnt Gulbrandsen wrote: > Malloc() is very simple: You ask for memory and get it. The negative > side > of that simplicity is that if you're out of memory (and that happens > occasionally if a server is run close to capacity) then processes die > and/or become unresponsive. Such is the tyranny of the Poisson > distribution. Not a problem at all. An API is a contract, violate it at your peril. The malloc() call's contract is you request memory with the understanding that "no" is a legal answer. If you fail to account for that possibility (tactics like preallocation) you either made a mistake or worse, failed to understand the nature of the deal. On the other hand, a tactic of simply allowing the process that hits the memory limit to die, thus freeing up some memory, might be the winning move. If you can't accept that, program in a language which deals with those sort of low level details for you and accept the solution it chooses when a request for memory fails. C isn't for everyone and isn't the best answer to every problem. After all, wrapping malloc in a simple test for NULL and exit beats just assuming any malloc will succeed. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Never say that again: was Debian is endorsed by Microsoft
On Sat, 2016-01-30 at 17:03 +, Nuno Magalhães wrote: > +1 > seems like kindergarten in here Think this is the best response yet in this overlong thread. Somebody said something kinda childish and offtopic and a polite corrective nudge to be a bit more adult was called for and should have ended the affair. But instead we got a full SJW meltdown and a Holiness Spiral started cranking up as too many people started reaching for their smelling salts and retiring to their feinting couches. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I never realised udev was that bad until now
On Wed, 2015-11-25 at 19:22 +, Dave Turner wrote: > Now I am trying my hand at Android development I find udev to be truly > vile. What idiot decided that you have to list your device in the > /etc/udev/rules.d/51-android.rules file before you can connect to it? > The file is already 13.7kB, bound to get larger with time, and I had to > use dmesg to find the vendor id for the cheap tablet I am using and add > it in! Not much to be done for it, just a consequence of how Android and USB work. This is why on Window you always need a special USB driver for the specific device, that is how it gets the USB ID info for your device. On Linux there is just a big file of known USB identifiers for things like adb since we just assume the vendors are not going to help with Linux support. Lots of good reasons to hate on udev, this isn't one. The fact the .rules files it uses almost have to be intentionally designed to resist human reading and editing is a good reason. :) signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Thu, 2015-08-20 at 07:10 +0100, Edward Bartolo wrote: > As it is, the frontend can connect on user request. The user can run > the frontend application, click connect and terminate the application > and the connection will continue to be functional. This is real KISS > in practice but I can also make the application automatically run on > startup of the OS. > > Then the frontend can automatically attempt a connection prompting > the user if no connections are set up. Just be sure to ask the user whether a connection is an 'automatically connect' sort of thing or not and save the answer somewhere. Automatically reconnecting to some APs, like your normal home or work one, is great. Others, not so much. > In the first case, I can hide the application window altogether only > showing it on failing to connect. That would be the 'UNIX Way', if a program has nothing interesting to say it should say nothing. Success is generally considered to be 'not interesting' since it is expected. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote: > The backends can be integrated into one single executable not to > clutter the sudoers file and to increase system efficiency. One suggestion here. Forget sudo and just make the backend suid root like other system utilities of this type. Just make darned sure there is no way to feed it command line input that could allow a root exploit of course. It can check whatever permissions like ownership of the local console/display, membership in wheel, etc. are desired to restrict usage to only some users itself. Maintaining rules in sudoers is less packagable even now that there is a /etc/sudoers.d directory to dump fragments into. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] straw poll, non-free firmware for installers
On Thu, 2015-06-04 at 02:52 +0200, Adam Borowski wrote: > On Wed, Jun 03, 2015 at 06:18:37PM -0500, John Morris wrote: > > Non-free software: NO, Firmware: YES. So ixnay on things like the Nvidia > > drivers but yes on blobs. The reasoning on where to draw the line is > > pretty clear cut. > > How exactly firmware is not software? Both are strings of bits encoding > commands for a processor living in silicon you own. So if the manufacturer puts the same firmware in an eeprom it isn't a problem? Or the BIOS itself? Are you running a Free BIOS? Do YOU know what your ACPI BIOS is doing right now? How about the CPU, those have loadable bits now, all entirely undocumented and closed. And lets not even open the can of worms over what Intel is doing lately in the of 'manageability.' I'm typing this on a Thinkpad, those have an entirely separate sixteen bit SoC 'embedded controller' with it's own OS that I have zero knowledge of what it is truly doing behind my back. In a more perfect world I'd agree that all that stuff should be open too, but it ain't, it ain't going to be. RMS managed to find -one- oddball machine that meets his definition of Free, if the vendor of that machine tried to sell them on the open market outside China they would find few takers. Bunnie's Novena 'Open Laptop' has blobs and closed 3d video drivers as well. Good luck tilting at this windmill. Where we can and should draw the line is in the kernel's address space. Blobs loaded into the kernel make the entire system untrustworthy and unmaintainable in ways a firmware blob loaded at initialization into an entirely different microcontroller managing WiFi doesn't. Not to mention that for regulatory reasons most vendors just aren't going to discuss the point with us. The situation stinks but changing it is beyond our current capabilities. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] straw poll, non-free firmware for installers
On Wed, 2015-06-03 at 12:45 +0100, KatolaZ wrote: > On Wed, Jun 03, 2015 at 08:37:22PM +1200, Daniel Reurich wrote: > > > > I'd like a straw poll on whether we should include non-free firmware > > in our installers by default. > > > My two cents on this point: I would really prefer *not* having any > non-free software/firmware in the default Devuan install. I have a position that appears out of the mainstream here but afraid I have to say that Fedora has the right policy on this issue. Non-free software: NO, Firmware: YES. So ixnay on things like the Nvidia drivers but yes on blobs. The reasoning on where to draw the line is pretty clear cut. If it comes down to the vendor shaving ten cents to save a serial eeprom, put the danged blob on the install media if the vendor allows unlimited redistribution. Doubly so for the blobs required to get connected to the network in the first place. But a closed driver polluting the kernel is right out. And no fair putting the non-free repo a single click away, they force all of the problem packages out to rpmfusion and do not even permit discussion of its existence on any official fora. Debian always has seemed to get this exactly wrong, creating pointless annoyance for the users while selling out the free software principles they yell so loudly about. They pretend to be RMS pure but make the non-free repos with all of the unfree crap a single install option away; but won't include the blobs on the install media to make that option meaningful if your problematic hardware is the network adapter. So in the end it makes Nvidia video, Adobe Flash and other horrid closed abominations easy to install and keep updated but a firmware blob that runs entirely outside of the CPU's address space stops install cold. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [dng] vdev status updates
On Thu, 2015-04-30 at 15:58 +0200, Joerg Reisenweber wrote: > Poettering clearly understood the implications and outright rejected the > rationale, by claiming nowadays it wasn't modern anymore to have a small root- > fs and a separate partition for /usr He is correct on this point. One should always obey the rules until you understand why the rule was made and the consequences of breaking it. Once upon a time the rule was that / should have everything needed to complete the booting of the system and to get a rescue shell. But Linux already violates that rule in that a naked kernel often can't access or mount / itself, which is why an initrd is usually used to start things off. Once that is accepted as something unavoidable, and it is unavoidable in a world of lvm, multiple software RAID implementations, wide variety of filesystems and such, the idea of / having the tools for mounting everything else is impractical. It made sense when / was on a fixed disk with driver support baked into the kernel and there was only one or two filesystems available. Now as for other assertions in this thread that the FHS itself is obsolete and violations of it should not be considered a bad thing, just no. No. As I said above, first read and understand it so you understand when it is ok to violate it and when it should be updated. The FHS was carefully designed to accomodate things like NFS root, readonly NFS mounting of parts of the system, mandating things like */share/ to only contain arch neutral data, etc. A lot of work is there to encode existing and historical practice in a lot more use cases than any one developer will likely be familiar with. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Two more reasons for Devuan
On Tue, 2015-04-21 at 12:06 +0200, Martin Steigerwald wrote: > Hi! > > Here are two more reasons for Devuan: I'd just say more signs that systemd was pushed into production way early and not new objections to the (widely held to be defective in the opinion here) design principles themselves. The failure to give a descriptive failure message when dropping into emergency mode is the only real unforgivable sin and it is not something the Pottering Cabal will object to fixing. The addition of nofail to go with noauto is properly documented in the fstab manpage so that isn't a bug, in fact it sounds like a useful addition which should be stolen/adopted. You really don't want a system with an unknown fraction of it's filesystems absent to attempt booting into a fully network connected state. No foul can be rightfully lodged against them on that score; Failing safe is the 'UNIX Way.' If you need to fix a machine which can't boot you need physical console access or an out of band management method such as IPMI. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Sat, 2015-03-28 at 10:49 -0400, Hendrik Boom wrote: > The very strict FSF interpretation is a useful extreme -- much like > the North Pole is for the idea of north, and absolute zero is for the > idea of cold. Now north is useful n our compasses, and cold is great > for beer (free or not), but few of us would want to spend our entire > lives at absolute zero or the north pole. Yes, but when nobody can agree on what "North" means we get chaos. Both the FSF and Debian claim to be the most 'Free.' Clearly both can't claim the title but each makes their case for a definition of 'Free' that leaves the other camp out and little good results from the schism. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Sat, 2015-03-28 at 12:33 +0100, Didier Kryn wrote: > BTW, I, like many others, find convenient to use e.g. Skype, and I > would prefer to run it inside a container. > >Over there, Linux installers are > > Shareware. All of them. I'm not a priest of St. Ignucius but the idea > > of the return of Shareware gives me the willies and is a future I do. > > not. want. > > > I don't understand your point. Are sharewares the present as you > first say or are they a future you don't want to see? I don't see also > why you call shareware the Debian installer. Go look at the Play Store. You can install Linux, including Debian, inside Android via fairly turnkey installers. All of them are Shareware. Not just most of them. Yes there is F-Droid, with all of a few hundred packages, everything else is nagware, spyware, adware or outright paid. F-Droid has Linux a Linux installer too and yup it too was Shareware last time I looked. They had to start admitting Shareware to F-Droid or it apparently would be an empty repo. Build a platform around the idea of untrusted apps and apparently they will come, add in seamless ads and micropayments and Free Software vanishes, Virtualization, containers and jails all have their place, untrustworthy (all closed source) software like Skype being a good use. But when we reach the point we routinely take the performance hit and run everything in one it will probably be because we have surrendered control of the repos to the untrustworthy... or soon will. > At the end, John, I don't find what you are proposing, nor even if > you do propose anything to avoid what happened with systemd and might > well happen again. Simple. Systemd is only the tip of the spear in what appears planned as a total reinvention of the OS. They aren't done yet. What happens when the next major component of that plan appears upstream is something that should be anticipated and planned for this time. We should not be caught unawares again. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Fri, 2015-03-27 at 16:37 +0100, Didier Kryn wrote: > Hi John, > > When I wrote anti-freedom, I considered a stricter definition of > freedom than GPL, beyond free access to the source and gratuitous > redistribution, including e.g. the absence of technical lock-in. I won't > argue about words though; it wouldn't be constructive. One way to > prevent the corruption mechanism you describe is to spell out what you > say we didn't: that "we are building a POSIX/UNIX/GNU sort of thing". Trying to take the high moral ground and claim to be shooting for a stricter freedom is what leads to RMS and Debian unable to agree on which is the more 'Free.' Debian rejecting the FSF's GNU FDL and RMS rejecting the easy availability of the non-free repos, blobs, etc. and all of the eyerolling that entails amongst us normal folk outside the priesthood. I was trying for a more practical line of division. To say, whatever guys, so systemd is Free Software; but that doesn't mean we have to like it. Which is likely to be important sooner than many think. Many of us were blindsided by systemd but I have started taking Pottering & the other Mad Hatters very serious now. Their failure to stabilize btrfs is the only reason they haven't moved on to the next phase of systemd/linux, gutting the distros and turning every user space program into an app in a container. Once that is done the apps don't really care what stub distro is hosting them and they can be delivered from a central Store instead of being built, packaged, maintained and curated by distros. Do we want to follow? It probably isn't wise to assume they will never make btrfs work, at best we lucked out and have gained a year or so of time before it starts showing up in Fedora. Now is the time to ask that question instead of when Debian is forced to follow RedHat again. Because Gimp the App is still going to be just as 'Free' as Gimp the package. Or at least it will be until you must get it from the Store with ads, nags, in-app purchase of closed source 'premium' filters, etc. But by that final phase it will be far too late to turn back. We haven't needed to run every user program in a hardened jail and a good argument can be made that the primary reason to do so is because you want to let in a lot of untrustworthy software that should be run in a secure container. See Android/Linux for what sort of dystopia the worst case scenario looks like. Over there, Linux installers are Shareware. All of them. I'm not a priest of St. Ignucius but the idea of the return of Shareware gives me the willies and is a future I do. not. want. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Devuan commitments - will trade-off be applied?
On Sat, 2015-03-21 at 17:04 +0100, Didier Kryn wrote: > However, the long term policy of Devuan can't be "We hate systemd > and Lennart Poetering". Instead Devuan should advertize the reasons to > reject software like systemd, in the form of a set of rules for > acceptability, in a sensible and attractive form, for users, > developpers, and distros to easily share. I see these rules as an > addendum to the definition of free software. Yea, this is a topic I have been pondering along with apparently many others. Easy to say what we don't want, but what do we want? I think I have an idea. Lemme start with an analogy that I think is similar to where we are now. Imagine a bunch of Boy Scout Troops in an area. Now imagine a large influx of new people into the area joining and contributing much volunteer labor, etc. Great! But these new people have some strange ideas. They want to organize baseball leagues into the activities. Ok, that isn't too strange, why not? Then they want to convert the normal summer camps into baseball camp. Oh, and you start noticing a lot of nike.com and spalding.com, etc. addresses on these new guys. Next thing you know they have simply outvoted the guys who think Scouting is camping, pinewood derbies and merit badges and by dint of numbers now own all of the physical and cultural assets, leaving the folks who wanted traditional Scouting to go found a new organization and start raising money to buy new campgrounds, design new uniforms, etc. The Troops are the distros, the newcomers are the Pottering and Gnome armies, nike.com is of course redhat.com and so on. That is sorta where I see us being, driven off of what we thought we had built as permanent institutions and forced to reinvent most of them again. But there are differences which is why I settled on this particular analogy; the differences point to what might be a better way to see the situation and the way forward. The situation described couldn't really happen because the BSA has a written statement of what it exists for and the National organization would eventually move in and set things aright. Debian didn't have one. It didn't really even have an unwritten one. Ask "What is Debian trying to build?" and get a different answer from every person asked. Building a Great Free Software OS is not an answer. systemd/linux is a perfectly valid direction if that is the mission. For that matter so is ReactOS but Debian was never about that, so why not? What has happened is that a decade ago, Linux was Linux, distributions had different package managers, included/excluded a few less used applications, upgraded to newer versions of things on their own schedule, etc. but they were all the same basic thing. Without having to spell it out, we all knew we were building a POSIX/UNIX/GNU sort of thing. And then things, quietly at first, changed. Where once there was one, one has already arrived and two more are clearly visible on the horizon. Google had the decency to go off and build their own infrastructure for their projects, unlike the Windows refugees and other misfits who have swarmed and seized most of the existing Linux distros and other infrastructure to host their fork. 1. For want of a better term, GNU/Linux. The original POSIX/UNIX Operating System with Linux as the OS kernel, Glibc (usually) as the C Library, a mix of BSD and GNU userland, the GNU toolchain and X for workstations along with one of the many Desktop Environments. 2. Android/Linux. Not too important for today's topic but it probably set some minds to thinking of the possibilities of putting a totally alien userland atop a Linux kernel. 3. ChromeOS/Linux. For now basically a mutant Gentoo but the wise shouldn't put a lot of money on that remaining true. Today it is only a distro but a full fork is likely. 4. Systemd/Linux, PotteringOS/Linux, POS/Linux, GNOME/Linux, whatever it eventually adopts as a brand. It ain't just GNOME3 and it ain't just Systemd. Reading what just Pottering has in store makes that clear; yum and apt-get relegated to 'distro maintainer use only', the OS shrunk to an anonymous stripped down platform to launch apps running in containers, all user space software appified into ad infested, in app purchase enabled security nightmares vended from App Stores that will need the extensive sandboxing planned for them. Seen this way, what we want is clear. We want what we wanted from the beginning, option #1. Simple, easy to articulate and pretty easy to decide to include/exclude features based on the criteria. And when it gets time to organize beyond some folks in an IRC channel, some thought into codifying exactly what the project is and is not trying to accomplish would be a good idea. The worry is that if #4 is really where Debian is being driven toward, sharing much of anything with them is strictly a short term solution as they are going to quickly become unrecognizable. > These rules
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Wed, 2015-03-04 at 02:02 -0600, T.J. Duchene wrote: > Yes. I can't speak for others, but I can implement far more cleanly > designed and reliable solutions using C than other choices. I can > certainly write "less code" using Python or Perl, but I can do exactly > the same thing with C by using a library. The other side of that argument is where I find the language wars end. K.O., not a technical. Everybody talks about code reuse and objects almost always enter the conversation around the same time. But there can be no argument about what code is the most reusable. Write the best perl code the world has ever seen and it will languish in CPAN, forever locked to the Perl world. It might become the number one included Perl module ever, perl programmers might believe you a living deity, but that is the maximum impact it can ever have. Same for Python, Java, Lua, etc. And to a great extent, even C++ suffers from the reuse problem, although the latest tools are finally allowing general purpose libraries without the old nightmares. Write a C library that is useful and people will quickly contribute small wrappers to call it from languages you haven't even heard of before the patch shows up. Code reuse? libjpeg.so beats the snot out of every object stack ever theorized by a comp sci prof, Had the reference implementation been written in the trendy language of the day it would be forgotten, a C implementation by someone else becoming standardized or the whole format failing to catch on due to the difficulty to implement the standard. The trick seems to be knowing what code is useful enough to justify a C library and what just needs to work and work today. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Plan for Devuan to use Mozilla products as is
On Wed, 2015-03-04 at 21:09 -0500, Jude Nelson wrote: > > Besides issues related to Chromium's poor support for privacy features, > > it also has no real security support. > > No comment on the privacy features, but I beg to differ on the security. > The fact that the Linux build of Chromium runs each tab and plugin in its > own seccomp'ed process and runs them all separately from a "kernel" process > puts the browser worlds ahead of Firefox in terms of security. Excluding > project Electrolysis (which I look forward to), the fact that Firefox runs > every tab in the same process means that one bad tab can compromise the > whole browser without too much effort. By contrast, Chromium's > kernel/process-per-tab factoring has led to secure browser designs [1] > where this class of exploit and others are provably impossible. Methinks you missed the point. Forget the kewl tech and concentrate on the people problem. Chromium/Chrome can't be secure on a Linux based on Debian, period. Full stop, end of discussion. They do not support anything but the current version and it quickly becomes unbuildable on a stable Debian release because they freely import dependencies on every new and shiny bit they see and expect it to be present in the very latest version. They don't even support RHEL 6, you have to grovel around on the Internet for wildly unsupported and dubious procedures (involving repackaging Fedora binary packages and shoving them down /opt and LD_LIBRARY_PATH trickery) to keep Chrome running, I know because I'm supporting fifty some odd workstations right now running CentOS 6 and need more than one browser available. They didn't just drop support for 6 when RHEL 7/Centos 7 shipped, no they dropped it over a year before the beta for 7 even appeared. And that is the 'Enterprise' distro with the big corporate accounts; Google doesn't give a crap. Moz didn't either, but when enough large sites complained about the constant version churn they at least delivered an LTS version. They are far worse than Moz when it comes to treating Linux (Android/Linux and Chrome/Linux excepted of course) as a red headed stepchild. If you want Chrome you run Windows, ChromeOS or a bleeding edge Linux distro. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Plan for Devuan to use Mozilla products as is
On Wed, 2015-03-04 at 14:25 -0500, Hendrik Boom wrote: > On Wed, Mar 04, 2015 at 07:45:22PM +0100, Anto wrote: > > Hello Everybody, > > > > I guess it is very likely that the first release of Devuan will use > > the re-branded Mozilla products. > > > Debian *could* have used the firefox binary direct from Mozilla, but > they compile everything from source, as it's the only way or them to be > really sure that the executable matches the source code. Close. You can't build a firefox package from the source and redistribute it unless you have a signed agreement on file with Moz Corp. For example, Fedora ships a locally built package with the logos and other branding intact but they (read RedHat) signed a trademark licensing agreement with Moz Corp, details not disclosed. Debian was offered a similar deal (again, exact details not public best I can remember) but it didn't matter because there was no way they were going to distribute a package that only they could rebuild and redistribute. It violates every ideal of both Free Software and Open Source. Not to mention the nightmare it would cause every distro downstream from Debian, like this one. g...@mozilla.org told me I had to rebrand WBEL's Firefox. Just rebuilding the unmodified RHEL source rpm was an unacceptable modification in his opinion. He never officially blessed my compromise of leaving the package and binary name firefox (since a key goal of WBEL was 100% compatibility with RHEL) and just iceweaseling the art, browser titlebar and menu icons, but I didn't get another nastygram either. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Kicking the tires on Valentine release
On Thu, 2015-02-26 at 00:08 -0300, hellekin wrote: > I'm impressed by all the testing you did. You may want to open some > issues in the gitlab. That would make a good test suite for the next ISO. Probably need to go get a Debian jessie cd and see how many of these problems exist there too. Doubt there is much to be done for X performance for example, doubt that is a devuan problem. Also just another problem, can't shutdown. Shutdown in a session just logs out and all of the shutdown, reboot, suspend, etc. options are greyed out in lightdm. Login as root and 'shutdown -h now' does work at least. But the login also showed a systemd-logind error about consolekit. Yanking this turd out by the roots is going to be difficult. And it will get worse monthly. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] Kicking the tires on Valentine release
Finally got around to seriously poking around with the Valintines Alpha release. Very alpha. Tried a default and an expert mode install, neither prompts for a root password and even if the option to create a user account is picked no prompts to actually do it appear. So I just did the basic install and rebooted rescue mode. A generic devuan user is present, no idea of the password so I set one for both it and root. On first login XFCE asks what I want for a panel config, I tell it one and it makes a totally empty one. I can manually add in a launcher, window switcher and notification area but this isn't looking encouraging. Installed into a vm with QXL for video, X sees that and looks like it is using it, but video performance is lousy. The install media is showing an icon on the desktop but it won't mount if clicked, permissions problem some sort, says "Not authorized to perform operation." /dev/sr0 is owned root:cdrom and the default devuan user is a member of cdrom so it isn't apparent what is going amok. Libreoffice is half installed, the base app launcher is present but none of the actual programs. No browser either. Didn't see any devuan readme or anything documenting any of these bugs. Added in the debian jessie repo and installed iceweasel and put MATE on the system. It can't mount the CD either, same error. On the other hand most problems were fixable and process 1 is init so Winning! signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] OT: Linux kernel and the force behind it
On Fri, 2015-02-20 at 14:32 -0500, Gravis wrote: > > RPC had already been solved in a general way by SunRPC (ONCRPC) before > either GNOME or KDE existed > > interesting I'd never read about those until now. however, there was no > GPL (compatible?) version for Linux (still isn't?) and the internet didn't > have it's information as organized back then. sure you can find > information easy with wikipedia... but wikipedia started in 2005. this was > also the era when xml was the solution to every problem which somewhat > explains why the messages are encoded in xml. who knows, maybe the did > know about ONCRPC but didn't like it and decided to make their own. Do man rpcbind then jump to the bottom and note the date and origin. And what the heck, the GNOMEs also had CORBA for an RPC method until they decided to abandon it. Just another case of NIH and those who hate UNIX being doomed to reinvent it... poorly. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] image upload
On Sun, 2014-12-21 at 19:58 +0200, Vlad wrote: > Isn't the Debian swirl logo GPL as well, I do not think t will be a problem > for Devuan to use it? There is no copyright problem with the image so the GPL isn't a problem, it is a trademark issue. Please read the trademark guidelines at debian.org. They are about as open as to usage as anyone has ever tried to be about using their logo and name, but it has to be used in connection to debian. Not a derived distro, debian itself. Recall that they even stopped the debian-multimedia repository from calling itself that. If the debian project doesn't release the packages they can't use the marks (the word 'debian' and the swirl image). And at this point I'd say the odds of a systemdless variant being accepted as an official Debian blessed effort is zero. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] TPM
On Mon, 2014-12-22 at 17:23 -0600, T.J. Duchene wrote: > What can it do in the right? Nothing that can't be done without the TPM > chip. One of the first things that you learn in computer engineering is > that anything problem can be solved on software or hardware. The only > difference is a question of efficiency. Keep to the fundamentals. TPM is all about trust. So long as I'm using it to enhance my trust that the machines under my control are actually under my control I deem it a good thing. If it is to be used to let somebody ELSE trust my machines in ways I can't control I'm probably not going to put up with it and disable the chip. Just that simple, just look at who is trusting who and the question of whether it is good clears up instantly. And yes, putting the thing in hardware does enhance security in ways software alone simply can't. signature.asc Description: This is a digitally signed message part ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
