Re: [DNG] printing in a D-Bus free system
Florian Zieboll writes: I suggest you get some workout and then target the original source of your frustration, constructively - instead of (cowardly) dissing 40+yo script kiddies (yeah, that's me^^). This brings definitely more fun and satisfaction, while providing at least some slight potential to change things in a positive and sustainable manner: for you, as for everybody else. I thought this morning maybe I should unsubscribe. I will do that. As you say, this isn't good for anyone. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Steve Litt writes: As one such back seat driver, allow me to explain. When you've been both programming and using for a long time, you get a feel for the many ways something can be done, ... I stopped here, because I remember what you wrote about Redis recently. Perhaps you don't have a feel for the many ways to do something with large data sets and shared-nothing architectures? You didn't let that stop you from writing about Redis. So here's your algorithm: if the software is familiar say something or other else if it's good exclaim how terrible it is else exclaim how terrible it is Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Dave Turner writes: which network printers should we buy? Look for something with wired ethernet, postscript and IPP, not under €300, not under 20kg for a BW laser. WLAN is okay but if the printer doesn't have wired ethernet, it's not targeted at the right market niche. HP, Lexmark, Brother and others have a long history of making good printers. As well as crap — people want small lightweight cheap printers so the same manufacturers make that kind of printer too. I've heard a rumour that HP has two printer divisions, printers from one are to be avoided, and the model numbers aren't conclusive evidence of origin. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
chill...@protonmail.com writes: lol @ about the browser taking longer to compile.. I have no doubt you didn't exaggerate this. That'll have been Chrome. A giant. It includes several compilers and lots of libraries. The only things I've seen that are comparable are gcc (over a gigabyte of source code when I had to look at it), glibc, llvm and kde. Maybe boost. Boost is okay if you have PCH support, but that's rare on linux. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
J. Fahrner writes: That's also what I do. I have a Brother DCP-7045N connected as network printer with lpd protocol. I can install it with a single ppd file, but then printing is VERY SLOW. Printing is fast with the Brother supplied "cupswrapper" driver, but this is only available as 32bit package, and that is ugly on a 64bit system. Has someone hints how to debug the issue with slow printing using only the ppd description (without cupswrapper)? The cups structure seems very complex to me, and I don't know where to start. It is very complex, hardly anyone need all of what cups offers. Try these: curl http://rant.gulbrandsen.priv.no/dl/test.ps | lpr curl http://rant.gulbrandsen.priv.no/dl/test.ps | lpr -o raw Is the first print job slow and the second fast? If so, cups is doing work you don't need. If not, it's something else. Are both slow or both fast? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Didier Kryn writes: Do you remember any of these comics where the driver of a car opens the motor to repair, throws away a bunch of parts, and then the engine starts again and the guy goes away with the car? Here we are with Linux. The BIG piece to remove was systemd, but there are quite a few others... follow my eyes. Be careful that you don't end up one of those backseat drivers who explain afterwards that implementing this or that should've been simple because obviously blah blah. Those people are terribly annoying to developers who've spent weeks or months battling tricky issues, trying to make the code work in many cases, for many users. Some things not mentioned today: Problems because rendering whole pages to bitmaps on the client needs so much RAM that the UI grows unresponsive, other problems if the client renders the pages in sequence to save RAM and the user closes the laptop once the first page starts printing, yet other problems if the printer runs out of RAM while rendering the current page because it's allocated too much RAM to buffering giant subsequent pages, yet other problems if the printer driver avoids using bitmaps and the printer firmware misrenders an embedded font. It's $%@#$!@#$!@# annoying when people come afterwards and explain how simple a task is, and clearly have no idea about the complexities and problems. Maybe d-bus is a poor fit for hplip. I don't know and I suspect you don't either. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Menelaos Maglis writes: Why should an application need a system bus to pass messages between its own components? CUPS is not using D-Bus and is able to print to other printers; only HPLIP uses D-bus, so far as I am aware. Why not keep using the same method/interfaces that are proven for decades? What is the benefit? How are printers from other manufacturers supported? FWIW, other printers are handled using some other IPC protocol. Same information sent back and forth, but a different socket and protocol. My Brother MFC8880 uses IPP and... I forget the name of the other protocol. Many HP printers can also be handled witout hplip. If you absolutely want something from HP, the M506dn looks like a fine printer that ought to work reliably for many years without peculiar host software. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
kato...@freaknet.org writes: yeah, namely. Why on Earth do we need dbus to send a print job over the network via lpd or http? The real answer is "we don't". The effective one is "the developers of hplip don't give a toss". Yet another answer is: The developers don't see another way that's both implemented and so much better that it's worth bothering about. (I'm using a computer with 16 GB RAM and four CPU cores to type a couple of parapgraphs of text now. Ridiculously overpowered for such a simple task. But I have the computer in my office, why should I bother to use anything less?) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] printing in a D-Bus free system
Didier Kryn writes: You're certainly right: it isn't simple. But it's essential, isn't it?. Graphics printing reached the personnal computer probably with the first McIntosh, in 1982. Not sure it's more feature-rich today than 10 years ago, when it wasn't depending on dbus. I wrote a printer driver back then. It used user-bus. "Tell me, dear user, whether the printer has and supports. A4 or funny american paper? Duplex?" If I were more ambitious I'd have asked more complicated questions. For example, if you want to avoid printer firmware bugs it's generally smart to send a large bitmap, but if you aim for high quality output and a high page rate, you want to avoid sending bitmaps. Can't ask users about such tradeoffs, they will be annoyed and won't be able to answer. These days you can ask the printer via d-bus. The printer knows more about itself than its users know about it. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The FSF seems to have finally sold out
taii...@gmx.com writes: I still have not received an answer from the FSF about if purism will be allowed to fraudulently market their products at libreplanet, they avoid the question as if I never asked it whilst answering my other questions. I've answered enough support mail to be able to explain why. Some questions aren't meant to elicit information. The questioner doesn't want information, not even if the question is "why did you chosse ...?". Rather, sending any sort of information back will just make the asker send something more. Answering such questions doesn't inform anyone, or achieve anything, it just generates more long mail. One learns to recognise this class of question. If you want an answer from the FSF, you have to ask qustions that don't sound as if answering would be a waste of time that leads only to more wasted time, with no productive result for either you or the FSF. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The FSF seems to have finally sold out
taii...@gmx.com writes: Purism is NOT free hardware and certainly not "grassroots" as their mysterious founder somehow has a bottomless pit of money to burn on hardware costs and propaganda campaigns. Bit of a dissappointment as mysteries go. Crunchbase and the team page suggest that Purism has a low burn rate, some income, an uncertain future and mostly grassroots money. https://www.crunchbase.com/organization/purism#section-locked-marketplace (Not going to argue about whether it's free hardware. You'll always be able to find something to complain about.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Request file system reviews and recomendations.
> ext3/ext4 are solid fs, and have > always been. the lost+found folder is a remainder of the ext2 era, and > is not even mandatory any more, AFAIU. lost+found is required since ext3+ext4 permit mounting as ext2, which requires it. A poor reason, perhaps, but put differently getting rid of a single directory would be a poor reason to remove that little bit of functionality. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Devs using OSx? was Devuan in the German Wikipedia
kato...@freaknet.org writes: Yes, I see. It's not that macbooks are preferred by developers. It's more like they are forced onto them by the marketing departments of their companies, who must ensure that their employees' laptops shine at least as much as their competitors'.and then we gasp at seeing how much shit we have to shovel off our front gardens. I don't know... I don't think any of my friends or past co-workers were forced. Free choice has been the norm where I've been, "any laptop offered by our usual supplier". Macbooks aren't that bad. Remember how difficult it can be to get linux drivers for everything, and what a struggle suspend/resume often is. After an evening of installation that nokia still doesn't sleep (which worked with ubuntu 10.04 and 12.04). I haven't brought that up on the list since devuan seems so server-focused. But let's not have any illusions: Macbooks have market share and it would be strange if it were zero among debian developers. A quick search found https://www.geekwire.com/2016/mac-overtakes-linux-as-developers-primary-os-windows-headed-below-50-market-share/ Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Devs using OSx? was Devuan in the German Wikipedia
kato...@freaknet.org writes: I don't see how macbooks could be the "standard" among developers (BTW, what kind of developers?). I cannot associate any feeling except *claustrophobia* to the very few times when I had to use a Mac. But perhaps I don't qualify as the kind of developer to whom Mac is to be consiered standard... Yeah, well, YMMV. I don't feel comfortable with my macbook either, and actually have reinstalled kde+devuan on my old, old nokia booklet and consider taking it on my next trip. The macbook has enough memory to be useful but the nokia has the right keyboard and... I don't know, there's something. I prefer linux. But at the companies that've provided most of my income in the past years, I can only think of two developers others who definitely didn't use Mac laptops. And at the IETF meetings I've been to, a large majority of those attendees who write code for a living brought Macbooks to the meetings. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian Devs using OSx? was Devuan in the German Wikipedia
Steve Litt writes: Is there evidence somewhere that Debian DDs use OS/x? It's so common among developers in general that it would be very surprising if zero debianites do it. Macbooks are almost a standard among developers, certainly a majority of the last hundred developers I've worked with used macbooks, perhaps even more than 90. Running production servers on linux is also common (linux is the most common OS even on Azure). Vagrant and Parallels support VMs well on MacOSX, and developers who want to test production-like during development often have Parallels or Vagrant. Connect the dots. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] NFS: was mounting /usr
Yevgeny Kosarzhevsky writes: I don't see that it will give lower security than any other FS in this case. Rick is trying to say: NFS has a poor reputation for accidental security misconfigurations. Something about the way NFS is configured leads even careful, clueful people to make configuration mistakes. NFS doesn't force you to make a mistake. Not at all. It just has a reputation for being a bit of a trouble magnet. Don't Xen and its friends offer read-only device exports from the host? So the the guest kernel can read a device from the host, but not modify it? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] mounting /usr
k...@aspodata.se writes:
If you know any specific packages which breaks the "separate /usr" idea,
please report.
Libraries in these
libdiscover2
libffi6
libgmp10
libgnutls-deb0-28
libgnutls-openssl27
libgssapi-krb5-2
libhogweed2
libk5crypto3
libkrb5-3
libkrb5support0
libnettle4
libp11-kit0
libstdc++6
libtasn1-6
are used by binaries in these
ping6
cgdisk
discover-modprobe
discover-pkginstall
discover
fixparts
gdisk
mount.nfs
mount.nfs4
rpcbind
rpc.statd
sgdisk
showmount
sm-notify
As you can see using e.g.
$ for a in /{,s}bin/*(.) ; do ldd $a ; done | grep /usr/
$ for a in /{,s}bin/*(.) ; do ldd $a | grep -q /usr/ && echo $a ; done
I decided not to report any bugs though. Initramfs has largely taken over
the classic role of the small file system on /.
Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] NFS: was mounting /usr
Steve Litt writes: It appears you're using NFS. Back in my youth, the wise men told me that NFS was a horrible security threat unless you also used YP, which was too sophisticated for me to ever figure out. That's a long time ago and the world has changed. Back then, the big problem was that people used "world-readable" and even "world-writable" settings, then then the world turned out to be a big place. Someone with UID 1026 somewhere could come along and read/write all the files belonging to the intended UID 1026. I remember NFS-mounting someone's file systems on another continent and snarfing ungodly amounts of porn, it must have been in 1990 or 1991. The world has changed. Packet filters and firewalls are now the default. The risk that someone can come and impersonate UID 1026 isn't a major factor these days. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netiquette Was: Re: Installing & running eudev broke USB drives auto-listing in Thunar.
Svante Signell writes: This is not the first posting from Eduardo to this list. He still has not learned netiquette, a very sad story. Sorry for raising this issue now, I just couldn't wait any longer. Regarding technicalities we are speaking about he is fully aware. Fix your own mail reader before you complain about how others quote. It still doesn't generate RFC 3676-compliant quotations. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Countering trusting trust (Was: forensics on systemd or journald logs)
Edward Bartolo writes: The parent compiler and the other compilers must produce identical code from the same source code. How is the control (parent source) compiler known to produce exactly the same executables as the other compilers? No. David Wheeler's dissertation goes into that in detail. Sixty pages of detail. https://www.dwheeler.com/trusting-trust/dissertation/ (As an aside, the people who bring up this compiler trust issue seem not to have thought about how it could work in the modern world. We have several compilers with open source and long version histories these days, and ditto operating systems.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?
Didier Kryn writes: Well, postgress is a database manager. You have a choice of several others; they must be able to deal with high fluxes of data. None of them is a critical system component. WTF? Postgres is a critical system component of every single server where I've ever installed that. The data in Postgres and the software that accesses it are the reason why the server exists at all. System logs are a critical system component and they don't face high fluxes of data. You can, in principle, use syslog for applications with a high flux of logs, but it's at your own risk. Are you saying one should not use syslog for events caused by untrusted users? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?
Aldemir Akpinar writes: No, I've actually asked an honest question. In that case you'll get my honest answer. I've implemented several file/network formats vaguely like that journal format, one of them has likely been used by millions of people. In each case, the team decided to use a header/packet format, because that made both writing and reading simple. In the case of the network format we additionally included a magic number to catch version skew, and did it using binary because that made for the simplest reading code. Reading a 16-byte header using read(2) is simpler than reading a textual header. I don't remember anyone on either of the teams suggesting that using text had advantages for developers or users. Generally we just chose what was easier to ship reliably and parse/generate with simple code. In one case we used binary because even though the data were readable text, they weren't editable (the actual format had non-trivial restrictions). I don't remember the details, but for some reason we worried that people would hand-edit files and cause problems deep inside the reading program. I find it totally plausible that the systemd people would design the format for similar concerns and end up a format where a fixed-size header includes a tag type and length, then a variable-sized packets mostly containing log lines, and then another header. That kind of thing is so easy to read and write using https://linux.die.net/man/2/read and its companion functions. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?
Aldemir Akpinar writes: Could you elaborate why are you comparing a relational database system where its files must be binary with a logging system where its files doesn't need to binary? You make it sound is if binary files were some sort of horror that requires special justification. Please argue the point. Does a text format justify x% performance loss? y% increase in line count or code complexity? Pick x/y. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..forensics on systemd or journald logs, was: rc.local removed from Debian 9, rly?
Arnt Karlsen writes: you appear to suggest that law enforcement wanting to read systemd journal logs, _should_ depend on the mercy of systemd developers not "filtering" away inconvenient evidence of e.g. systemd developer wrongdoing from said law enforcement. That's routine. Few readers read everything that can be read. For example, look at postgres. Its binary file format reveals quite a bit more than you can get using psql, and by design: The writer and binary format are intended for storing things quickly and reliably, and the reader for reading what was stored. Anything that's in the file but wasn't stored by instruction of an SQL user is uninteresting to psql, and the file format writer has no particular reason to avoid storing other information. If you really want to look at the details in postgres, you can take a good guess at whether two rows were inserted at the same time or one later than the other. That's why forensics people use the files. Systemd is about the millionth system to join the club. Flame postgres and vast numbers of others before you flame systemd. Or better yet, limit your statements about systemd to what's correct. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] rc.local removed from Debian 9, rly?
Olaf Meeuwissen writes: Crying wolf like this time and again is not doing Devuan any good. Amen. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please provide systemd-free libreswan package
John Hughes writes: The lkml.org archive contains a broken link. How odd. There's another message from Linus with the same subject: https://lkml.org/lkml/2017/10/26/524 That one's to the point... Linus may/will not react to conspiracy theories about possible future commits, but it there's actual breakage he'll right it as soon as someone says "kernel commit x breaks mdev/mdevd by removing y; libudev copes since commit z so libudev users should upgrade libudev and kernel in lockstep" for concrete values of x, y and z. BTW, it took Linus three weeks to switch to all-caps this time. That's a record, isn't it? He must be growing mellow in his old age. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please provide systemd-free libreswan package
Didier Kryn writes: That's why a bunch of people have endeavoured replacing systemd-udev by mdev or mdevd, something much simpler to configure and not locked-in. The only issue now is that sysfs is unstable on purpose to force libudev on people (sysfs is developped by the same persons which develop udev). Linus accepts that? Isn't that precisely what he exploded about a few weeks ago? https://lkml.org/lkml/2017/10/26/511 Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
One more. When we say entropy and random numbers, we generally mean completely unpredictable. Intel's RDRAND, ekey, presumably ID-Quantique's solution and others rely for their entropy on quantum physics. If our understanding of quantum physics is correct, then by constructing such and such circuits, a certain bit flickes unpredictably between 0 and 1. The linux kernels' u/random relies on math. According to fairly well understood areas of math, an observer who sees the output cannot predict future output. Havege relies on complexity. It says that somes system can be too complex to understand, that modern computers are such systems, and so measuring some aspects of the system produces a stream of completely unpredictable numbers. (It also uses testing to find out which aspects will do.) According to your descriptions of what you want (Taiidan), the middle is the right one for you: It's essentially 100% open source and the others require you to trust either quantum physics or that impossible complexity is commonly available. You may not understand either the math or the C but both are accessible to you. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
If this is not your field of expertise the you should not call Intel's solution junk. It will not help with disks. What it helps with is applications that need properly independent random numbers often. A VPN server is such a case, it needs a few bits every time a client opens a connection and the clients may be enemies of each other, so it is preferable that each user's session keys have absolutely no relationship to those of other users. A VPN client does not have this need. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Different philosophies
Nate Bargmann writes: I've also used Procmail for an equal length of time and it is now claimed to be "unmaintained". Who claims that? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RMS: was Google abandons UEFI in Chromebooks
If I am remember well, MS Windows (the operating system) does have a micro-kernel, but is it more efficient with an extra layer of intercommunication? Windows NT is based on DEC VMS, not a very modern OS ;-) https://en.wikipedia.org/wiki/Dave_Cutler Based on VMS, right, like Linux is based on Multics ;) Seriously, efficiency isn't the prime consideration for microkernels. Reliable performance is a better key term. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
Didier Kryn writes: The distinction trust-zone vs normal doesn't look very different of kernel-mode vs user-mode, does it? Or, for that matter, like the privsep distinctions used in some programs. It's all the same kind of thing. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
Martin Steigerwald writes: I don´t know much about Trustzone. Do you have any links to a good explaination of it (preferable from a non-vendor source)? Not offhand, sorry. But let me summarise the one I read: You can put code and data in a part of RAM and then turn off regular access to those pages. After that point, the memory is only accessible when a CPU core is in a special mode, the "secure world". Then there's a way to switch to that mode and call functions, and a way to start a thread in the special mode. A file system encryption system or keystore would do the former, a hypervisor the latter. Notably, it's regular RAM and not a dedicated core. You can easily tell how big the secure world is and how much CPU the hypervisor uses. There's no builtin hypervisor, it's something the boot process has to set up (or not). You can imagine why DRM people like this, and that's what gets the media attention. But it's a nice building block for other things, and if it isn't used it's just a small bit of disused silicon (small size is a selling point). Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
Martin Steigerwald writes: I wonder about ARM64 as an alternative? But they have some Trustzone crap if I remember correctly. ARM64 is fine from a performance viewpoint. The mobile phone vendors have spent a decade optimising ARM SOCs for performance on small batteries. I haven't found laptops with ≥8GB RAM so far though. Personally I consider the Trustzone well-justified and good. It makes it easy to provide security regimes that rely on an unchangeable past and already-closed windows of opportunity. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Google abandons UEFI in Chromebooks
Dr. Nikolaus Klepp writes: Nice. But it they suffer from the "not invented here"-syndrome: instead of using prooven good busysbox, they rewrite userspace in GO .. oops, who "invented" Go and wants to push it to the users? They use the linux kernel, but suffer from NIH syndrome? Has it crossed your mind that they might consider busybox deficient for reasons other than NIH? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
taii...@gmx.com writes: I can't imagine it being equivalent to a (non-intel/amd) hardware source of entropy when it comes to quality of entropy - have there been any quality analysis performed? Yes. But it misses the point. http://www.irisa.fr/caps/projects/hipsor/publications/havege-tomacs.pdf and http://www.irisa.fr/caps/projects/hipsor/publications/havege-rr.pdf state it clearly: Havege is not a entropy gatherer like the Simtec device or the new Intel CPUs, both of which rely on quantum physics. Neither is it a PRNG. Instead it is a third class, namely an observer of unreproducible state changes. Havege says: Modern computers can be measured more accurately than they can be modelled, and the additional accuracy provides a stream of numbers that are practically like entropy. They use the word "practically". After reading the source and both papers, I accept that there is such a stream. I just don't accept that the stream is as fast-flowing as they think. Now, can you analyse the speed of the stream in a way that's really different from what's in their source code (and mentioned in their papers)? AFAICT you cannot. Their own analysis goes as far as reasonably possible. What remains is the philoshophical point: Do you classify an observer of unreproducible state as a PRNG or as like entropy? It is a shame IDQ is the only vendor with a PCI-e device, and also the only vendor it seems that offers something quality and obtainable (I can't find an open source hardware entropy device that is really for sale right away And IDQ won't take you seriously? Long ago I shared office with an extremely capable salesman for a while. He was a bit of a cynic and very, very skilful. The company's top salesman in terms of money. One of the things he told me was about prospective customers who choose not to buy the product because it doesn't X. He said: "Those never buy. If we X they just find a missing Y." The prospects worth taking seriously were (according to him) are the ones who bought from a competitor and said they'd switch if X. Their present outlay proved their sincerity in his eyes. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
Olaf Meeuwissen writes: I have used the `haveged` package to keep my /dev/urandom "topped up" when randomizing disks. Greatly shortened the time needed to fill my disks. No idea about the quality of randomness, though. I looked at it now. It seems to observe some real entropy, but I think they overestimate the amount. Some of the events they count show up in some/many counters, and I don't see any attempt to estimate or account for covariance. So, yes, good stuff IMHO, but I don't think it's actually hundreds of megabits per second. Still, even 1kbps of real entropy isn't bad. Arnt ___ 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
(Sorry, forgot to send earlier) Steve Litt writes: Something that used to take no more than correctly configuring grub now requires execution of the volumes of information in these links, with much of that execution being trial and error because of different UEFI/secureboot implementations. That sounds rather like booting itself, as well as reading data from drives and the network. Both were awfully simple until encryption and security and all that ruined it for us. When I moved from DOS to linux I wrote a network storage driver for DOS (as a client) and linux (as server). The client side was just over 1500 bytes of assembly. No crypto of course. Today I'm sure I couldn't even parse the TLS handshake in that. I also wrote a minixfs r/o driver in less than 640 bytes of assembly (the total project was 640 bytes, reading the file system was the biggest chunk of that). Again, no crypto. Today dealing with LUKS would need at least 6400 bytes of assembly. Stuff is so simple if you can assume that noone will try to decrypt your packets, read your files or attack your system. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
Didier Kryn writes: I've read previously on this list that secureboot doesn't prevent booting from a usb key... Or did I misunderstood? People spread too much FUD. Various people have asserted, without naming names, that some/most vendors do not allow you to delete keys from the list of accepted keys. If you can control the list of keys, and your own key is the only one you accept, then you can prevent booting from USB sticks. (I won't post any more in this thread now; nothing new is going to be said anyway. Sigh.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
taii...@gmx.com writes: No you aren't. Intel ME + "Secure" boot non-owner controlled firmware code signing enforcement (probably hardware enforced via boot guard, so one couldn't even spend the thousands to have it removed via a coreboot platform port) If you can't execute whatever you please on all the processors then it isn't yours. It sounds good when you put it like that. But you're telling someone who has added an easter egg to a very widely used open source package, and noone ever found it. I didn't even try to hide or obfuscate that, still, noone ever found it (or at least mentioned it on any of the relevant lists etc). I know a maintainer who put something controversial in the code he was maintaining, too. None of his users noticed until he removed it himself. He and I could both put code on millions of people's systems that none of them discovered. He hid his stuff in an unrelated commit, I didn't bother even with that. Noone noticed. That's how effective open source is at revealing to hardware owners what software they actually run. You personally don't even known to within a factor of ten how many lines of source code are installed on your most-used linux box. Am I right? Closed-software users don't know, you don't know either. The control you think you have is mostly an illusion. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
Didier Kryn writes: For me the things which need to be protected are 1) the data 2) the OS, to avoid backdoors I can't see any need to protect a motherboard against booting from a "foreign" disk. To access the data: Boot from foreign media, modify or replace the usual boot partition so it looks right until it asks for the disk encryption password, turn off the host, wait for the owner to turn it on and type in the password, done. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
kato...@freaknet.org writes: Yes, but what about *adding* your own keys? This does not seem to be a popular option, AFAIK. Of course it isn't. Who has a reason to talk about it? Microsoft doesn't talk much about that, because Microsoft wants most users to use Windows Upgrade and get timely upgrades. They document what people like us need, and their corporate salespeople will tell their corporate customers how to guard against industrial espionate, but their message in public is naturally about the common case: MAKE WINDOWS USERS UPGRADE AUTOMATICALLY. The people who maintain UEFI-related software for linux won't talk much about it, beacuse they're employed to make things like Ubuntu work smoothly. At the end of a long day making UEFI work with Ubuntu out of the box, they may wrote a blog post or post on linux-kernel, and show an example of something. That something's very likely going to be about the stuff they did at work that day, not about the opposite. The individuals who wrote the spec and code may all be friendly to people like yourself, but friendliness is not attention. They have little reason to talk about your usecase. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
kato...@freaknet.org writes: I don't know much about signed bootloaders, and i will try to re-read the thread to fully understand your statement. The short version: You can remove keys, so that only your own key is valid for booting. If you're then careful about that key, then later physical access is almost useless. I personally think that works as described. If the vendors add secret backdoor keys and it's ever revealed, big corporate customers like Siemens and Petrobras will scream at them, a prospect vendors prefer to avoid. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] UEFI and Secure Boot
kato...@freaknet.org writes: And what if you want to use your own unsigned bootloader? Why should you ask someone else the permission to boot your own machine? o_O Because I want deny people with physical access the ability to boot unsigned bootloaders. I am both the owner of my hardware and the person who usually has physical access. Requiring signed boot loaders is way to transfer rights from latter role to someone else — in my case I'd prefer to transfer them to the former for all portable hardware, so for my next laptop I'm going to do the MOK stuff described on this list last week. Arnt ___ 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
Dr. Nikolaus Klepp writes: Sorry to say, it's not. These keys don't allow booting your retail windows. Uh-huh. Are we talking about black helicopter keys? Arnt ___ 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
Dr. Nikolaus Klepp writes: Well, that's not true: If you are lucky, your vendor installed a bios that allows you seamingly do so. But most likely he didn't. Most likely his implementation has a backdoor for windows. You're saying most vendors do this? Not just some but MOST? Name one or two vendors who do it, please. You'll need to see his contracts with M$ to verify this. Sometimes somebody down the sales lane will give you some hints, but don't count on it. Booting Windows from a USB stick is an easy way to test it, right? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ID Quantique "Quantum" PCI-e RNG's - does anyone have more info?
taii...@gmx.com writes: I found this seemingly cool product, a pci-e hardware RNG that produces a large stream of "truly random" "quantum" random numbers. ... I am curious what the deal with this is, does it really work? what is the use case for this? does anyone here have one? I have a competitor, http://www.entropykey.co.uk / apt-get install ekeyd, which I fear isn't being made any more. It's useful sometimes. "Arnt, marketing just signed a deal fory x with y, and we need 5000 coupon codes, they really should be impossible to guess". What these devices does is basically keep /dev/random topped up, even if the host is a rackmounted server and you need a half-megabyte of random bits in short order. I bought them when some software insisted on using /dev/random (because security), emptied the pool and an important service grew unresponsive. Arnt ___ 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
John Franklin writes: That’s not an apology. Would you like to try again? I'm not Steve, but the occasion fits: Tobias, until I read your posting a couple of days ago I did not realise that UEFI/Secure Boot can be configured such that ONLY my kernels can be booted, not even fresh install media from the vendor. Thank you very much. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debian testing drop redis non systemd
jaro...@dyne.org writes: Same here, its a core part of many software projects, not only web based but also on embedded systems and micro-service related. Totally offtopic but some if you will be fascinated by the references to redis in this talk by John Regehr: https://youtu.be/Ux0YnVEaI6A Summary: Compiler research (and in particular superoptimiser research) involves spending a LOT of CPU time on finding optimisation candidates and judging their potential. Hours or even days to compile an executable. Caching across invocations helps speed that up, and sharing redis dumps is useful for discussing results and reporting bugs. Arnt ___ 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
Alessandro Selli writes: Plus, it's purported security is mostly a mith. It only checks if the first-stage bootloader was signed by a known, authorized key, everything else is as exposed to malware and rootkits as it's always been. It protects from one of the smallest attack vectors that was used to compromize machines. Isn't it the ONLY way to protect against that? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New behaviour under Devuan.
Rowland Penny writes: Please stop being obtuse, You know very well what I meant. I do indeed, and I think you're wrong. Devuan has taken a no-systemd decision, that's all. That isn't a promise from anyone to provide alternatives in any other question, or to make alternative packages. Not even an implicit promise. Devuan has to make some decision for you, but you accept them by accepting Devuan. I accept them, sure. What Devuan doesn't force on you are things like, what GUI to use (or force you to use one), sudo, su or anything like this. More importantly, it doesn't force systemd on you. As far as I can tell, the decision is "devian policy's is devuan's, except ABSOLUTELY NO SYSTEMD". Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] New behaviour under Devuan.
Rowland Penny writes: This is all down to the sysadmins decision and I thought one of the main ideas behind Devuan is that nothing is forced on the sysadmin. Systemd isn't forced on you. LOTS of other things are, starting with the choice of .deb as package format. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] upgrade from Debian stretch to Devuan ascii?
Edward Bartolo writes: With a compromised CPU that has questionable smaller cores running a HIDDEN OS, I cannot see what advantages anyone gets by installing grsecurity. This is worse than having a compromised machine that is always connected to your computer. Bah. We already know that a CPU can be compromised by changing a single NAND gate and that it can be done at the fab, without the CPU designer team's knowledge. In other words, you can raise security requirements so high that literally no computer builder can satisfy them. This does not mean that every lower requirement is pointless. For example, some attack kits must be hoarded. They're very powerful, but every time they're used they risk disclosure, if the victim notices and sends the computer off to someone like Citizenlab. The attacker has great power and is almost unable to use it. That's a threshold. A useful security threshold. With such hardware around, GNU/Linux has just become yet another Windows. The only advantage _till_now_ is GNU/Linux still allows user-centred configurations and modularity. There is yet the other uncertainty of what ISPs do with data travelling through their systems. Even if users set up completely secure systems, their data still has to travel through an ISPs infrastructure. You've just discovered that windows and friends aren't all black and linux not white. Indeed, both are patchily grey. I personally prefer linux, it gets the job done and much of it is lightish grey. Getting the job done goes before "and" and security after, because if the job isn't done, security protects nothing and is worthless. I am starting to believe computer security is an unattainable Utopia. That's a good book, I recommend reading it, if only for its descriptions of Utopia and attainability. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Could not open a connection to your authentication agent.
Arnt Karlsen writes: ..which idea is worse then, keep having dbus interacting with ssh-agent, or ripping out dbus of Devuan? Ripping it out looks like a lot of work, based on just a quick look at dpkg/status. A lot of nontrivial things to think about. I noticed a printer library on the list of users, for example. As it happens, I've been involved in writing printer drivers. I don't know how that library uses dbus, but I do remember how difficult it was to deal with paper sizes, and due to lack of suitable IPC APIs was a big factor. Dbus is an ICP API. Perhaps the change is simple, but it may also be something that requries days or weeks of work. $ grep 'Depends.*dbus' /var/lib/dpkg/status | wc -l 179 $ 179 tasks to do, and some of them difficult? That may be months of fulltime work. Dbus would have to be really very bad to justify that. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purism Librem and disabling Intel ME: it can be done [ Re: TALOS 2 - The Libre Owner Controlled POWER9 Workstation/Server ]
Alessandro Selli writes: What makes you think IBM is more trustable than Intel? Who, other than IBM, produces Power8 CPUs? Are the blueprints publicly available? You're just raising the bar to the point where noone can possibly build an acceptable product. (Not just you, Alessandro, most people who post to this thread.) Suppose the blueprints are available. Then you could scrutinise them. But how big is the chance that you would notice a single gate out of place? Or worse, a single gate that has a legitimate purpose but could be subverted by a fab-time attacker? We already know that a single-gate attack is possible: "In this paper, we show how a fabrication-time attacker can leverage analog circuits to create a hardware attack that is small (i.e., requires as little as one gate) and stealthy (i.e., requires an unlikely trigger sequence before effecting a chip’s functionality)." Google and read it if you want, the paper makes for sad reading. Or you can make a decision about what to guard against and stop worrying about the rest. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purism Librem and disabling Intel ME: it can be done [ Re: TALOS 2 - The Libre Owner Controlled POWER9 Workstation/Server ]
taii...@gmx.com writes: I take it you work for purismraptor has made a legitimately owner controlled computer - whats stopping you? Is that an actual owner-controlled computer, or is it controlled by whoever is at the keyboard? Or is it controlled by all the people who have a certain password? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] TALOS 2 - The Libre Owner Controlled POWER9 Workstation/Server
Rick Moen writes: Having the i.MX6 ori.MX8 CPU 'separate' from the baseband controller (a term on which they have not yet elaborated), but the latter remains deeply problematic, being a proprietary black box with proprietary, opaque firmware. Really? I suppose you've dealt with as many ISPs as I have... some of them give you a cable of some sort, some of them send you a router to put on customer premises. In the latter case, some people just connect the ISP CPE to their network, but you and I make a tiny DMZ and route everything via a router of our own. Once I used the exact same kind of Cisco as the ISP, which looked a little superfluous. But that's really a small thing. A few watts, a power cable. Back to the phones. If you have proper control over your phones's baseband, you're relying on the telco as a proprietary black box to forward your packets and calls. If your baseband's a blob, but you do have a proper DMZ between your hardware and the baseband, then you're relying on two black boxes. IMO: Much of a muchness. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] noatime by default
Simon Hobson writes: [1] The drive "most likely" does not know about partitioning, and even if it did, it would be very dangerous to assume that any space not occupied by a partition was "fair game" to be erased since there may be other ways the space might be used (for example, the way Grub uses space before the first partition). So if the space has been used before, re-partitioning without somehow informing the drive that the excess space is now free, will not give any benefit. Hm... I had to trace the commands issued to a buggy drive a few years ago, and ubuntu certainly TRIMmed the entire drive as part of installing when I told it to get rid of all the existing data on the drive. I think the TRIM was issued by the installer, but don't hold me to that. (The bug was related to SATA command timeouts and very large TRIM commands, FWIW.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] noatime by default
If you want to do it it can be done, though. You can intercept the mount system call using LD_PRELOAD and about 10 lines of C, or you can write an /etc/fstab line for /mnt that specifies noatime and your usual USB device (perhaps sdb1, YMMV). If you write the fstab line at least "sudo mount /mnt" will mount with noatime, and you can write something udevish that runs mount and does it the way you want it. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] noatime by default
Narcis Garcia writes: USB drives use filesystem as were formatted. When they are formatted in ext4, support atime. Indeed. I assumed you meant USB drives generally, not ones restricted to work only with linux. Sorry. I was asking for a method to set noatime by default. Is udev/eudev triggering program involved for USB cases? It depends. Neither my laptop nor my desktop do at the moment (devuan/kde and oldishubuntu/kde), but I'm sure there are linux variants that do. And when user clics over a not mounted device through file manager? Not with the files manager I have installed and hardly ever use, but I'm sure there exists either one that does or that has been forked to do it, so try yours ;) The only relevant option I see is whether to automount none, previously known or all sticks. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] noatime by default
Narcis Garcia writes: Does anybody know some way to configure an already installed system to mount points with noatime by default? Edit /etc/fstab. I'm specially interested for USB pendrives, that are automatically mounted in a desktop environment. USB drives generally use some sort of windowsy file system that doesn't support atime at all. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which desktops are available in Devuan?
Android apps run in one process each, and anything in the background may be killed at any moment. If you are in the background and the foreground app needs memory, you just die. If the system invokes you, you do not get another process, you get another thread in your existing process. Thus, ulimit is enough for Android. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] openssl/libssl1 in Debian has disabled TLS 1.0 & 1.1
ael writes: I am happy with that. Just as long as one can enable it when *necessary*. You have a compiler and building is easy. What is unacceptable is for Devuan to take away the freedom to read email or prevent communication with devices which cannot be updated. Keep in mind that compiling with SSL2/SSL3/TLS1.0 support opens the door to downgrade attacks. The process works like this: 1. Someone discovers an attack against, say, 40-bit DES. The only way to remain safe against the attack is to stop using 40-bit DES. 2. Some maintainers leave in support for 40-bit DES to it can be used "when necessary". 3. A MITM attacker persuades one end of a connection that the other end supports nothing better. 4. The connection now uses 40-bit DES, which the attacker decrypts. You want support for the vulnerable protocol when YOU think it's necessary. But the code doesn't ask WHO thinks it's necessary, you or an attacker. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which desktops are available in Devuan?
My office desktop runs KDE on Devuan, without any problems. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Excessive bounces
For what it's worth, SPF, DKIM and DMARC were developed by largely different sets of people, who disagreed without each other about what was acceptable tradeoffs, what was doable and more. The "they" you mention act senselessly because it is not one set of people. Patching up email against spam is a hard problem and you cannot expect wide agreement about the best tradeoffs. IMO the right solution to the problem at hand is to delete dkim signatures during list processing and to tell dmarc supporters to either have their cake or eat it. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Please keep 32-bits alive
Hendrik Boom writes: How much source code actually cares whether pointers are 32 or 64 bits? How many packages are ctually affected? Any guesses? a+b. a = the number of things whose maintainers all use 64-bit OSes, and chance to have a relevant bug. Given the number of small teams, I'm not at all surprised if a hundred or more of the tens of thousands of debian packages are affected. b = the number of packages whose memory usage is heavily pointer-dependent and that are used in big deployments. That does exist (say among people who bin-pack microserver shards across iron to fill both RAM and CPU capacity) but I'm willing to be that for devuan's purpose b<π (those people compile). Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Desktop-Environment] Cinnamon and MATE
Rick Moen writes: Quoting KatolaZ (kato...@freaknet.org): All those users are being left without any other choice than throwing their hw away by many distributions, without a concrete motivation (well, except the usual "it's old so it must be thrown away", which is as popular as lame these days...) Why should Devuan do the same? IMO: Because of the year on the current calendar. An old colleague of mine, when I worked at a linux distributor, put it like this: "The good users are the ones who choose because is what they want. Advertising support for old hardware is looking for trouble. What you get from that is users whose hardware is too old or too halfbroken to run windows. They're a support drain, and they're always telling others how doesn't work." Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [Desktop-Environment] Cinnamon and MATE
Juergen Moebius writes: No, not only Devuan. You forgot the great "Slackware", the mother of Linux distributions. If we're going to go into ancient history — Slackware was (simplifying) a fork of SLS, but SLS wasn't the first either. Either ABC or H. J. Lu's nameless microdistribution might be considered to be the mother of linux distributions, IMO ABC is closest to that epithet. The first to use the source+patches approach was called Bogus Linux. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Forums: was I have a question about libsystemd0 in devuan ascii,
Rick Moen writes: I'm curious who implied this. I didn't, for one. My impression is that you're talking about something nobody upthread has been talking about, and asserting that they did. You weren't around then — at least a year ago Edward made a bit of a nuisance of himself on this list (all well-intentioned, no evil trolling or anything like that), was tolerated for a while, then not any more. One of the VUA cabal members told him off and he stopped it. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Listserver configuration
If the name server receives a question via UDP, that's how it will answer, necessarily. The client could have asked via TCP, but it doesn't know how large the response will be when it sends the question. The general intention here is that the client will receive either an ICMP message or a reply, if no reply arrives (some people firewall away ICMP in the name of safety), the client is supposed to time out and retry via TCP, but that timeout can be too slow. Last time I ran into that the upper-level protocol timed out the DNS query before the DNS library switched to TCP. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] grsecurity ripoff by Google, with Linus' approval WAS: I have a question about libsystemd0 in devuan ascii,
Please pay attention to what Linus actually wrote. Linus complained about the patches, not the grsecurity code. I know (from other threads) that he's not in love with the code either, but what he actually complained about is the patches. Linus wants patches with clean version history, and he wants commit messages that describe the problem solved. More than one commit per problem is okay, but changing two unrelated things in one commits is not. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] scanner dependencies
Hendrik Boom writes: Sounds like sonething that should go into Devuan jessie as a bug fix. After someone tests it, of course. "Of course"... Which would you rather have, an untested fix or a known bug? IMNSHO that's an insidious question and neither a yes or a no is "of course" correct. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] just curious,
It is nicely stable already. After all, it is mostly Debian. Just use it. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] git.devuan.org migration
jaro...@dyne.org writes: for now however I can anticipate that a "shared" server that is also used for other things can host a mirror (if bandwidth is enough) - and we will document also how to have a package mirror. However for other uses we likely need to have a dedicated server. I have two, at two different well-managed colos in Germany. I could provide simple mirror blah already, one of them could also host VMs if qemu can be persuaded to leave the routing table alone. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] PHP-7 on Devuan
Better yet, don't change in a year. Cross-distribution apt-get is risky, in the sense that you may often be the first person to try your combination. I would rather look at building from source or contributing packages to devuan, so as to avoid that risk. Contributing also takes time, but you get to decide when. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] dovecot / exim4 / system users -- restriction of emails per user
IIRC this isn't at all simple with that software. For mostly poor reasons
that may have changed since last time I looked.
You could approximate it with a bit of hacking, though: Use exim to force a
bcc to something like policyviolation@asdf, and use a generated sieve file
for that address to check whether anyone's done anything forbidden. The
generated sieve script needs a long list of clauses like this one, which
permits aaa@asdf to use sales@asdf and blah@asdf in the From field:
if allof(envelope "from" :is "aaa@asdf".
anyof(address "from" :is "sales@asdf",
address "from" :is "blah@asdf")) {
drop;
}
The default action at the end of a sieve script is to file into the inbox,
so the end effect is that your policyviolation@asdf account receives only
rule violations. Read that mail whenever you feel BOFHy and have a great
day — one way or the other.
Arnt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] sane-utils depends on libsystemd0
Hendrik Boom writes: So... does sane need saned? Do the scanners have to initiate communication with the computer for which there always has to be a daemon running? That's not what sane does. Sane doesn't need saned to scan; I use devuan and a scanner without even having saned installed. Saned is what you need if you want to connect a USB scanner to host A and then run scanning software on host B. It makes A pretend to be a network scanner that B can use, rather like how my scanner (a Brother MFC-8880) offers its services to everyone on the net. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
kato...@freaknet.org writes: Unfortunately we are already paying the consequences of badly-written software implementing oddly-designed solutions to non-existing problems... Indeed. But what's your point? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
kato...@freaknet.org writes: I genuinely don't understand why the kernel should know about the internals of running processes, or get notified if a process is "ready" to do whatever it is supposed to do, or get queried by other processes which would like to access this kind of information, or maintain such information in the first instance... Indeed. Particularly in light of the modern fashion of running things on other hosts reachable across the network, perhaps via load balancers that complicate the availability state machine. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Why I don't want to have Pöttersoft on my system
Aldemir Akpinar writes: It also has the grand finale: poettering locked and limited conversation to collaborators 2 hours ago Makes sense. Nothing new was being said, just old stuff repeated, and the bug was fixed three weeks ago. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] message from rdiff-backup
I do the same and suffer the errors. A backup without an exception is a backup without a buggy exception. "Oh, the exclusion that was meant to not back up coredumps also excluded the vital config file foo/cf/core/vitalfile?" I am not making this up. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] message from rdiff-backup
That message means that the file changed during backup. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and oss(4)
Klaus Ethgen writes: I wonder if Devuan will stay with free software like debian was long time ago and let the user choose what to use or if it follows debian in only supporting one (non-working) sound system. There are two questions here. Open source support is limited by a) volunteer availability and b) project policy. Which part are you asking about? Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Alessandro Selli writes: This still doesn't explain why they decided to force-feed Google's DNS server on the user without prompting the poor fellow any possible choice. "Your network sucks. Do you want to [ ] use google or [ ] just give up?" BTW, how many Debian installations are performed in hotels with lousy DNS resolvers? s/performed/performed by someone with debian commits bits/ ;) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Simon Hobson writes: For the rest of us, if we have no DNS servers in resolv.conf then we expect the system to respect that and not do DNS resolution. That is the **ONLY** correct behaviour. What is absolutely, 100%, not acceptable behaviour is what's been done - to silently do something that no sane admin would expect, and many people have objections to doing. Even worse is when there isn't a mechanism for turning this off. You can also make a similar argument that if the software requests DNS lookups and nothing's been firewalled, then the **ONLY** correct behaviour is to fulfil the request. There is a contradiction here. An operation is requested and configured to be available in the firewall, but configuration blocks it elsewhere. Calling any particular behaviour a 100% solution is IMO naïve. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Rick Moen writes: You might not have noticed that you were strenuously agreeing with me. I mixed up the participants in the thread while reading through the posts. Sorry. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
I wrote: This year I've seen... No I haven't ;) Happy new year, everyone! Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Alessandro Selli writes: Why are Debian folks so eager at increasing Google's traffic and "free" "services"? Just a guess: Because so many of the resolvers at random hotels suck, and that suckage causes support load. This year I've seen almost infinitely slow resolvers, resolvers that filter out some RR types, and resolvers that break if you issue more than n concurrent queries. I don't stay in that many hotels. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Steve Litt writes: What's wrong with 8.8.8.8? It's Google's public DNS, and for me, it always works. Didn't work for me at the captive portal in the hotel I was in two weeks ago. There are two kinds of hotel networks that block 8.8.8.8: Hotels in China, and ones that block all DNS except their own, just so they can serve you a stupid redirect to their stupid login page. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] how to clear DNS cache
Rick Moen writes: One recursive namserver per LAN is obviously better than several on grounds of multiple considerations that I won't belabour here. Is it, really? Significantly? It eases the load on the root and big-zone TLDs. I've heard that most of their load is caused by other factors, though, including misconfigured brokenware and malevolent software, so I'm not sure whether additional load from correctly caching resolvers really moves their needle. It eases the load on auth nameserver for zones that don't use load balancing, if any such zones are big enough to be used by many people on a LAN, yet small enough to be used infrequently. (If they're big enough to be used frequently, then the big savings come from caching, and all the shared cache does can do is improve the hit ratio from ninety-foo per cent to ninety-bar per cent.) The DNS packets are small, the network is faster than a decade or two ago, the load situation has changed with all the load balancing and evilware... I think the value of shared caching resolvers is shrinking towards zero. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Networking on installation: was Devuan GNU+Linux, Beta2 release
Yes, it has to point to something the client knows. Android uses a gstatic.com link. The key is that the client knows to expect a particular response, but the captive middlebox does not. Thereby the client can find out whether there is a captive middlebox or not, by seeing whether it gets the expected response or a redirect. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Networking on installation: was Devuan GNU+Linux Beta2 release
Hendrik Boom writes: Worst is probably the connections that seem to be wide open, but aren't. The ones where you have to open a browser and look for a page and get an interception page instead asking for your credentials. Those are detectable: Open http://wlanhelper.devuan.org/.html in the background when joining any open WLAN, and if that returns anything but 404, then either open a browser if exactly one user is logged in and has an X console, or else ifdown. I'll submit a patch if that bit of the code devuan-specific and the patch is welcome. (I have no particular desire to touch debian's patch process.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] trouble with wifi one step away
Hendrik Boom writes: My laptop will connect to the coffee shop'w wifi modem, which has IP number 172.16.0.1 and gives me IP number 182.16.0.194, but there seems to be no route from it to anywhere, not even DNS lookup. Can you tcpdump the DHCP sequence? This sounds like a bug; 182.etc is not inside the DHCP server's network. A linux box should not end up with an IP address outside the DHCP server's address/netmask, even if the DHCP server is returning nonsense. The linux box should either get a usable address or no address at all. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Full-sized ARM based computers
Well, v6 has been stable for quite a number of years now, while v4 had a security-relevant change in 2012, so you may consider the dust on v6 to have settled already. (RFC 6598.) Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev - scanner
The key here is that linux doesn't assume one user. You get to answer, from first principles, whether a particular USB device belongs to user x or to root, etc. The mac has a stronger assumption that your mac belongs to you (which is why the default hostname is "Dave Turner's Mac", etc) and what you plug in does too. I like the way KDE handles/handled USB sticks: The version of KDE I'm running asks me about USB sticks the first time and remembers each stick forever, so if I plug in my keyring stick now the linux box will automount it. That would be a fine way to handle phones too. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] F1 and special usernames on the login screen
Steve Litt writes: I hadn't thought much about several people using the same computer for different GUI tasks in the last 12 years. It happens. There are some family-shared tablets with >1 account. Rumour has it it's rare, although I've never spoken to anyone with numbers and without an NDA. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] vdev
So that when you arrive in the office, you get a view of the world that includes the s3kr3t servers in the office (i.e. split horizon), and when you later leave the office, those things disappear from your view. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Would you guys hate me if...
Hendrik Boom writes: Liinux has a decent file system. It has a decent set of tools for manageing them. Its file systems even have mechanisms for storing many small files. It even has symbolic links, that can be see-also's. I really don't see that the problem of storing menus requires further invention. BTDT. Once you get translations the number of files balloon to the point where people complain (reasonably or not), and if you use directories you soon enough need to store something more than just the directory name, which the linux file system doesn't easily accommodate. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux-Speakup-friendly emails: was question about mailing lists
Steve Litt writes: So let me ask you: What standards of quoting are compatible with Linux-Speakup, and could you please elaborate on concise and meaningful quoting as it relates to people reading my replies with Linux-Speakup? Can't say about that specific reader, but in general, stick to RFC 3676 for parser happiness. 3676 is a slight variation of text/plain, with a specified quoting style and soft linebreaks. Blah blah SPCRLF blah is a soft linebreak, blah CRLF blah is a hard linebreak. It's really good for paragraph-oriented text, but poor for ASCII art. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wirth's law
Rainer Weikusat writes: This can be avoided by ensuring that each thread which needs to hold A and B acquired A first and B second. Every time I've run into that in the past ten years, the reason for the deadlock was that subsystem X locked B and subsystem Y Z, and then someone made a function in X call one in Y. Arnt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
