Re: [DNG] ..tenacity replaces Audacity like Devuan replaces Debian? Tenacity ditches spyware.
Dr. Nikolaus Klepp wrote: > This is a strict no-go. Any software even with the "option" to get you > prosecuted by any countries laws will get you in trouble. Any sane person > should stay away from that crap as far as possible. Unfortunately you’ll struggle to stay away. There is a lot of free/open software that can get you into trouble - without you doing anything wrong. DeCSS is still (AIUI) illegal in the USA - but is needed to watch a DVD on Linux. Many tools (e.g. WiFi scanners, network sniffers) can get you into trouble because they have a use as “hacking” tools. Basically any tool which could be considered to have sinister uses, even if that’s only in the eyes of a technically illiterate law enforcement officer, can get you into trouble. Heck, even using a web browser can get you into trouble - there have been a few cases of people, for example, simply editing the URL and being accused of hacking. Now, back to the original story. If any business collects data, then they may be required to hand that data over to the law enforcement authorities in their country in accordance with the laws of that country. That is certainly the case with the UK and the USA - but normally there is a process that must be followed rather than them simply turning up and telling you to hand it over. In other countries it may be “accepted practice” for someone to turn up and tell you to hand over data, with a firearm to provide some incentive to comply. Furthermore, in some countries there is a legal requirement to collect certain data - there certainly is in the UK with some service providers. The best option from a privacy PoV is for anyone to collect the least amount of data that’s compliant with their laws - that way they minimise what they could be asked to hand over. If you are interested in finding out how users actually use your product, e.g. which features are used and need maintenance vs those that are unused cruft, then you might want to collect some usage stats. IFF that is done openly and with the user’s permission then I don’t see that as a big problem - each user can make the decision as to whether they are happy to help with that. The biggest problem with Audacity is that they did it without adequately explaining what they were doing, using a third party with a “dubious” record on privacy, and generally having a track record of putting self interest above the interests of it’s users. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] random sudden stops
Hendrik Boom wrote: > When the machine stops I cannot access it by network. Even existing > connexions stop working. Have you disabled console screen blanking (IIRC “setterm --blank 0”)so that any messages put out are readable ? Perhaps you’ve already tried that and there’s no clues given ? Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Twitch and 2FA (TOTP)
Bernard Rosset via Dng wrote: > Something very important is implied there, and probably only a few will > notice it: there is a requirement for a smartphone. In general, it’s also possible to do 2FA using applications on a desktop. But, what I don’t like is the assumption prevalent behind a lot of this (my bank keeps trying to persuade me to use “their app”) that we’re happy carrying around the keys to our lives on something that is a) easily lost, b) easily stolen, c) liable to run out of power at inopportune moments, or d) can break/be broken. b) is the worst case of course - because then the thief not only has your 2FA keys, but they also have access to your backup routes (e.g. SMS and email) as well. And for as long as it takes you to realise that it’s gone and be able to access the various services and change the access to them - which might not be easy if you are away from home and without access to your desktop or laptop. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] FHS deficiencies: Was: Er, Not that way ? .Re: Announcing Devuan 4.0: Chimaera!
Olaf Meeuwissen via Dng wrote: >>> Might I suggest $HOME/bin :-) >> >> ~/bin isn't ideal for two reasons: >> >> 1) It's integrated with all sorts of config, cache, and who knows what, >> and can easily be lost or wiped out in a re-installation. > > In the case of $HOME/bin getting lost or wiped out in a re-installation > I'd argue you have bigger problems than just losing $HOME/bin. You have > most likely lost all of your $HOME, and maybe even other users' $HOME as > well. Agreed. The most logical place for personal stuff is in your $HOME. If it’s a mess at home, then tidy up a bit - better than deciding home is too much of a mess and effectively just moving house to start again at another home. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] To cc or not cc. (was: Devuan with usr merge?)
Steve Litt wrote: > The biggest accomplishment of this DMARC/DKIM thing was to make email > such a mess that it sent even more of the dummy dwobes to Facebook, a > private club having a monopoly over communication. What could POSSIBLY > go wrong? I don’t think it has. From past experience, it’s taught many people that “the only email you should use is gmail (or one of a handful of others)” because of the things they broke (deliberately). At my last job, we ran a mail server for our clients. When I started there it was (IIRC) iMail ruling on Win NT and it got hacked regularly. I got asked if I could knock something up - which I did, a “temporary” setup with linux, Postfix, Postfixadmin, Amavis, and a few more bits. It was temporary for quite a long time, and needless to say, quite reliable in spite of me only having “hand me down” hardware to run my servers on - I was putting hardware into service that was (as my manager described it) 9 year past it’s swap out date ! But I digress. After a good few years, I did a refresh and built a clustered system with before-acceptance mail scanning - something the big guys don’t seem to be able to manage. As a policy, we’d setup clients with their own email to match their websites - so (e.g.) bloggscoffeeshop.co.uk would have (e.g.) i...@bloggscoffeeshop.co.uk for email. I’ve always thought it looks just plain naff when you see a custom website with a nice domain name - and a generic email like (e.g.) blogg...@btinternet.com. But, many clients just refused to have two email accounts on their computer even though we’d offer to set it up for them. So many were simple redirects so that mail to i...@bloggscoffeeshop.co.uk just got redirected to blogg...@btinternet.com. Which worked fine until Google, MS, and Yahoo between them broke it and we had to explain to our clients that Google, MS, Yahoo, et al had broken their email setup deliberately. But still, many refused to simply setup their nice email address as a second account in their client - I’ve noticed that even MS have relented and the built-in client in Win 10 now allows this, the built-in piece of rubbish in Win 8 didn’t. So many simply changed the address on their website to be their ISP provided email. And as far as the clients were concerned, the problem was our broken mail service - hence they need to use a “proper” one. I did look into applying SRS, but with the combination of tools I was using, that broke one of our key anti-spam measures. So as far as I’m concerned, the fact that they broke stuff was quite deliberate. The likes of Google, MS, Yahoo, etc would far rather people use their systems (so they can monetise their emails) than have it easy for smaller outfits to run fully functional emails systems. And between them they had/have enough of the market to simply declare something broken, change it, and force the rest of the world to change to suit them. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
e now a lot of “admins” who really don’t have the skills outside of the toolset provided by SystemD. Just like there are a lot of Windows admins who can’t cope with anything beyond randomly changing settings in the GUI. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
emD project has an incentive to maximise their intrusion into every aspect of system operation. Because the harder they can make it for devs to make they software run on SystemD or any other init system, the more they can make other software depend on SystemD and thus make it harder to keep SystemD optional in the wider view. So having had SystemD create such a gulf between the requirements to run on “traditional” systems dn SystemD systems, effectively any shim would have to recreate a heck of a lot of SystemD. And we all know that such a shim would be trivial to write given the well documented and stable interfaces between the SystemD components >> Peter Duffy said on Thu, 25 Nov 2021 13:51:18 + >> >>> I've said it before and I'll say it again. All this could have been >>> avoided - if systemd had been made optional from day 1. People who >>> liked it could use it; people who didn't like it could use something >>> else. And in the Debian world, I distinctly recall there being an air of “don’t worry, it’s optional anyway” alongside the “and it’s only another init system” arguments. It was only once it was too late and the GR had been fudged to get a pro-SystemD vote that people realised that it was never going to be optional. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] system administration of non-systemd distros and releases
Steve Litt wrote: >>> I've wondered for a long time if it would be independently possible >>> to make systemd optional. >> >> I think you found that the answer is no. > > I think you might be pleasantly surprised. In, to use the term loosely, > "discussions" with systemd's biggest fanboy whose initials weren't LP, > I found out, according to him, that the only two systemd services that > can't be removed are PID1 and journald. If the fanboy is correct, then > you can install the runit process supervisor (not the whole init > system), and one by one, disable systemd's handling of the other > services, so all systemd does is launch runit and act as a logging > mechanism. I’ll admit that I’ve not really followed the subject all that much, but it’s my understanding that you can’t just replace a couple of services. It’s not that you can’t replace a SystemD service with something else, but the way SystemD has been extending it’s tentacles into all sorts of stuff that wasn't broken (and replacing it with broken alternatives - c.f. ntp). I may be completely wrong, but it was my impression that they’ve been so trigger happy replacing established APIs with “better because it’s new” APIs that a lot of packages won’t work OFF THE SHELF without SystemD running and servicing those new APIs. So I think it comes down to whether the devs for the package you want to run took the time to encode multiple “if systemd then do X else do Y” (or ifdef buildforsystemd then do X else do Y) stuff in their code. At some point, if you are writing with an eye on distros that all run SystemD then someone could be tempted to just write “do X” - and then that package won’t work if the API for X isn’t present. And of course, at some point (if there isn’t already) then it’s likely that SystemD will introduce something whose semantics are different - so it’s not just a case of “call API X or call API Y”, but case of do a bunch of stuff one way or do it a different way. So the statement you’ve quoted may technically be correct, but may also be “somewhat misleading”. Lars Noodén via Dng wrote: > That's not too far off from new cars as they are today. They are lousy > with sensors and everything is tied directly or indirectly to the > dealer, either through proprietary programs + proprietary protocols or > service contracts or both. You can't change your own oil though I think > changing the wiper blades on your own is still allowed. And by "you" I > mean the ostensible owner or an independent repair shop. > > The cars are not recognized as computer systems, but as Cory Doctorow > pointed out they are a computer you put your body into. I have only a > weak grasp of the situation, having kept my head in the sand as long as > I could, but I think two non-excusive approaches to solving the car > software / protocol problem might be through software liability (as > outlined by Geer and Kamp [1]) and through the ongoing attempts to > restore the "right to repair" as led by Rossmann [2], in particular the > latter which is picking momentum in regards to heavy farm equipment. I can’t speak for commercial vehicles or agricultural machinery, but for cars things took a positive turn in the EU many years ago. At one point, car manufacturers were heading down the road towards “only a franchised dealer can do X, Y, Z” and independents would be locked out - due to lack of third party diagnostics etc as we’re seeing with (for example) John Deere. The first I recall was BMW where only franchised dealers were allowed access to the unit needed to reset the maintenance light - but as I recall, it wasn’t long before the protocol was reverse engineered and third parties started selling the ability to non-franchised dealers. The car manufacturers rolled out all the familiar reasons why only franchised dealers should be allowed to do anything - the “think about idiots fitting substandard parts” one being the biggest. But the rules were changed, the car market was stripped of it’s exemption from certain competition laws, and suddenly it was illegal to have franchised dealers with defined geographic areas, it was illegal to tie franchised dealers to only dealing with the one manufacturer, and the biggest benefit of all was that it was illegal to withhold maintenance and diagnostics information from non-franchised dealers. I can’t remember whether it was part of this or a separate rule change, but at some point it was made a legal requirement to implement a standardised diagnostics port - and the EOBD port was born. So I guess we have it easy over here, and I hope things change in that way for you over the other side of the pond. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] networking thinking
o1bigtenor via Dng wrote: > 1. is my splitting the network system into the three parts a good idea or > should I truncate parts 1 and 2 into the router? If you would please give > reasons - - - please? Six of one, half a dozen of the other. Sometimes having separate boxes is good, other times it isn’t. For example, if you run a router doing NAT (on IPv4) behind a firewall, then the firewall doesn’t see details of where the traffic comes from - only the mangled version where it’s all coming from one address. On the other hand, sometimes it can be tricky making everything work on one box - e.g. doing traffic shaping both ways when there’s multiple internal networks can require an intermediate virtual port (an IFB, intermediate function block, in iptables terminology) to route traffic through and I never did get the hang of that. > 2. are there any good sources for information on and about networking? > debian has moved to nftables from iptables - - - is devuan doing > similar? Everything has moved, or will be moving, to nftables - it’s a kernel thing. There’s a shim layer to provide an iptables interface to help people through the transition, but I suspect it might struggle with some of the more complex stuff due to differences in semantics between iptables and nftables. > Where does one find information to enable a firewall that works yet > isn't stupid? I’m afraid that’s up there with the answer to life, the universe, and everything - and in this case it’s not 42 ;-) Back when it was part of the day job, I would “sort of absorb” bits and pieces until I knew enough about networking to be dangerous. After that, it’s a case of recognising when there’s a gap in the knowledge and filling it through reading/research. Sometimes a good starting point is to have a specific thing you need a pointer to and asking others. In the past my preferred firewall was Shorewall - it’s quite a steep learning curve, but not as steep as native iptables, and not as limiting as most other firewalls. However, I’m not sure of it’s current status as it was always very tightly bound into the semantics of iptables and would probably need a bottom up re-write to work well with nftables. But while the learning curve can be steep when past the basics, the examples will let you get common setups going very quickly. But by far the biggest thing that I liked about Shorewall was the “everything is in a bunch of text files” approach - meaning that you can look at the files and see what’s going on - and, I know this will frighten many used to GUIs, you can put comments in the files to tell you what is going on ! At the same job I mention below, some of the fireballing was down with Zyxel appliances - all though a “rubbish” GUI that makes finding anything difficult and documenting it impossible. Almost a write-only system. For the ultimate in control, eschew packages and get down and dirty with the native commands - i.e. learn how to drive nftables directly. tito via Dng wrote: > I personally prefer x86 hardware for this kind of things Me too, though there’s some fairly decent small computers about these days. IIRC the rPi4 has a “real” network interface, and gigabit at that - so it would probably make a fairly decent “router on a stick”. Router on a stick being a reference to something like a lollipop where there’s a “blob” on the end of a single stick. You can use VLANs up this single ethernet link to separate the different classes of traffic - e.g. a VLAN for the connection to your ISP, another for a management subnet for the switches etc, another for the main office LAN, another for a guess WiFi, … At my last place I had a Debian VM (pre SystemD) with something like 3 DSL (PPPoE) connections, another via an ethernet provider, a backend for inter-server traffic, office LAN, guest LAN, management LAN, and possibly something else as well. Most run on separate VLANs over a single ethernet interface. And all configured with Shorewall. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] lpr print pdf file landscape orientation
Marjorie Roome via Dng wrote: >> How does one print a PDF with landscape orientattion? >> > Isn't the page orientation used encoded in the pdf? > > To change it, other than by shrinking the page down so it fits on the > paper in landscape orientation I think you would need to use a pdf > editor to reflow the content. > > If you have a document or image that you are converting to a pdf then > if you format the document or image landscape then the exported pdf > will also be landscape. Yes, the PDF is a complete description of a number of pages. It is possible to change some things by pre-pending some Postscript to change the meaning of some verbs, though it’s so long (couple of decades) since I last fiddled at this level that I can’t remember the details. So you could turn pages around (rotate the content by 90˚), but that won’t reflow any text/re-arrange the contents. One trick I do recall doing was where we printed inbound faxes on our SCO OpenServer system at a previous job. I changed the meaning of the “showpage” operator so that instead of just printing the currently imaged page, it would add a header to the page with key details (date, time, number, etc) and then print the imaged page. At the same place I also did a custom text-ps script, adding in options to use some of the printer specific features we had on our printers - like doing A3 landscape on a laser instead of printing to the old green lined fanfold. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] RGBling
Syeed Ali wrote: > I have a closed case yet light still leaks out of the back of my PSU. > > Numlock, desktop speaker, mouse DPI setting, monitors even when asleep, > my KVM, and every single port on my USB hub all leak. And then someone invented blue LEDs and suddenly the dark is lost to little floodlights in the colour our night vision is most sensitive to - as every designer decided that it would be “cool” to have a really bright blue LED on an many devices as possible. Just don’t get me started on the id10t who thought making the sleep LED on the front of a MacBook Pro “throb” just to make it even more difficult to ignore. For the last 21 months, my office has been the spare bedroom. I have to switch everything off at the wall when it gets used as a bedroom. To your list add network switch - which flickers all the time with background traffic even when the computers are all off. It’s something when it’s possible to walk around the house lit only by little LEDs - even the smoke detectors are tiny little floodlights, thankfully only dim and green. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nftables firewall and fail2ban replacement.
onefang wrote: > My main problem with fail2ban is that it fails to ban. Or rather it does > ban, for that one rule I wrote myself, but not for any of the built in > rules, but then it releases the ban, even though I have told shorewall to > ban that particular IP. So the IP ends up being unbanned, coz fail2ban > says so. > > Yes, I'm aware you can configure fail2ban to shift from temporary to > permanent bans for persistent rule breakers. Would be good if the built > in rules actually worked. From experience, the built in rules worked last time I set a system up - worth checking all the config files as (again from memory) none of them are enabled by default. But what I did for the persistent offenders was to write my own rule (don’t remember any details now) that basically looked for repeated bans and then blocked them for a long time. That allows for users (or yourself) accidentally triggering the first rule - you just have to wait for it to time out - but will ban persistent offenders quite quickly as they’ll still be hammering the system when the first rule times out. Another thing to be aware of is that applying iptables drop rules to existing connections doesn’t stop the traffic. That’s important when trying to deal with UDP traffic - that may only apply when there is packet mangling (e.g. NAT) and so contract comes into play, or when the traffic terminates on the box you are trying to firewall it on. But TBH it’s a while now since I dealt with th and I don’t recall any details other than needing to clear entries in the contract table to actually stop traffic - I vaguely recall having to log onto the main router and drop it there sometimes. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nftables firewall and fail2ban replacement.
Antony Stone wrote: > The one feature I'd like to see on fail2ban is multi-server communication, so > that if one of my machines has a reason to block an address, it tells all my > others to block that address as well. That’s also possible to “roll your own”. I was considering this at my last place, but never got round to doing it. The only hard bit is messaging between machines, but my plan was to send a message to the outside router so it could block the address at the perimeter. One thought I had was to use syslog to send certain messages to the router’s syslog so fail2ban could pick them up and apply rules. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] bash / quote weirdness
Steve Litt wrote: > This is one reason why, in shellscripts, you > need to quote almost all variables: So they act correctly with the > space laden filenames that windows dwoobydogs just love to create. Not just Windows users. I regularly use spaces in file names. There’s an argument that computers should be tools, not slavemasters. I’m sure you’ll remember going back a few decades how interacting with computers meant that the human had to learn how to deal with the computer’s way of doing things. So, for example, typically when writing a document you had an edit mode from which you couldn’t print, and a print mode (menu) from which you couldn’t edit - you could not simply write you document and when ready just tell the computer to print it. I recall a lot of resistance when Apple brought out the Mac and suddenly programmers had to learn how to write programs that did what the user wanted - when the user wanted. So, for example, open an editor, write your document, and whenever you want - hit Cmd-P (or choose Print from the File menu) and it gets printed, right there from inside your “edit mode”. And now most people stuff like that for granted. rings have shifted from the user doing the work to make the computer side easy to the user expecting the computer side to do the work - after all, isn’t the purpose of computer to do “stuff” for us ? Similarly with file names. Once upon a time the human had to adapt to what the computer supported - such as fitting your entire file name into 8 characters. Now the computer (mostly) supports what is natural for a human - and that includes using spaces in their writing. After_all_it_does_seem_a_bit_un-natural_not_being_allowed_to_use_spaces_in_your_writing_-_it_would_make_a_hard_to_read_book_! Another OT anecdote. This talk of spaces and quoting reminds me of an issue I had to deal with a couple of work hats ago. I had some users who would struggle sometimes to log into their terminals on the SCO OpenServer system. When I watched them carefully, I’d see them mistyping either their username or password, so for example assume their username is “username”, they might mistype it thus : “usermname” rather than “usermname”. Because it looked OK on the screen, it was hard to persuade them that what the system saw them type was “usermname” and not the “username” they could clearly see on the screen. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [OT] Apple Mac programming (was: bash / quote weirdness)
Hendrik Boom wrote: >> I recall a lot of resistance when Apple brought out the Mac and suddenly >> programmers had to learn how to write programs that did what the user wanted >> - when the user wanted. > > Sounds good. But for the first two years the Mac was out, programmers > couldn't use it to write programs. To program it you had to use a much moe > expensive machine, and Apple Lisa. > > Not what I, a potential user, wanter. > > After two years, somewone marketed a Pascal interpreter -- not even a > compiler. Indeed, there were multiple issues at first - but programmers resistant to doing a bit of work so the user didn’t have to was one of them. Back in 84 I was at Uni and took out out for a Test Drive and Apple was calling it back then - no intension or ability to actually buy one ! I do recall when I returned it and being asked what I thought, replying along the lines of “nice machine, pity they are trying to cripple it with s**t marketing” as the test drive program was (IMO) really horrible. At work I have to use Windows laptops, and it’s a constant reminder of how Apple brought standardisation every time I try Ctrl-W and remember that in Outlook it’s Esc to close a window, or in IE Ctrl-W doesn’t work if it’s a PDF in the window. MS can’t even standardise basics within it’s own dross, so it’s no wonder no-one else bothers either. We had the full set of Inside Mac back then - strange to think that the entire programming manuals (dead trees back then) were only about 3” thick back then ! But one of the 3 manuals was entirely dedicated to what the UI should look like and how it should work. Was it Borland that did the Pascal first ? Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Qt, KDE, unbelievable
o1bigtenor via Dng wrote: > Now if all that advertising was actually good for something except making rich > people richer - - - - Or simply paying for things that people want but don’t want to pay directly for ? The problem isn’t the advertising pe se, it’s the lengths advertisers (and some of the sites/programs that use them) go to in order to make their ad stand out more than the other garish ones served either side of it. IFF they were plain and static so we could ignore them, and IFF the noxious cesspits that serve some fo them could be trusted not to serve up malware as well, and IFF … well then there’d be no problem. But it’s this race to make them ever more difficult to ignore, and the evidenced absence of any morals in some parts of the industry that makes then a problem. As someone else pointed out, my magazines are full of ads, in part that’s how they are paid for - but those are static, they don’t jump out of the page and hit you in the face. Without them the magazine (or society subscription) would need to be higher and then less people would sign up. And yes, I have over the years seen ads that fit the “ah, I’ve been looking for something like that” category. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What is your take on finit?
Steve Litt wrote: > * It requires each daemon to background itself. Eww, gross! Does it ? I read the examples as supporting foreground processes : > # The BusyBox ntpd does not use syslog when running in the foreground > # So we use this trick to redirect stdout/stderr to a log file. Also the syslog and kluged examples both show the use of -n to avoid backgrounding. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Configuring ethernet port for IPv6
CP packets at the hardware level, thus blocking third party software from working. As a result of this, a network cannot disable SLAAC and use DHCP without breaking Android devices - and so persists a situation where some people want to add everything from DHCP into RAs because DHCP "doesn’t work”. Steve Litt wrote: > On my next router, (probably OpenBSD/pf), I'm going to block all IPV6. > I enjoy that the badguys have to jump through one more hoop (NAT) to > hit me where it hurts. NAT doesn’t really offer much by way of security - the “everything appears as one IP address” being the only feature I can think of. A stateful firewall will give you the same level of security for IPv6 as it does for IPv4. With IPv6 however, you gain the ability to hide like a matchstick in a very large forest. The MINIMUM address range an ISP can give you is a /64 prefix, giving you 2^^64 addresses to play with - and as above, by default devices will pick random addresses within this range. That’s a MINIMUM of 2^^32 times the entire address space of the IPv4 internet all to yourself ! That’s the minimum. Recommendations are for ISPs to delegate at least a /56, and preferably /48 - that gives you 256 (2^^8) or 16636 (2^^16) /64 prefixes to do with as you like. So trivially easy to have separate prefixes for multiple wired networks, WiFI SSIDs, etc, etc. All with global addresses - just configure your firewall to allow/drop traffic according to your requirements. Unfortunately, it appears some ISPs can’t shift the “addresses are scarce” mentality, and offer only the minimum of a single /64. In terms of privacy, it simply changes from “everything behind one address” to “everything behind one prefix and using random addresses that change periodically”. Even if someone knows your prefix, they need to scan 2^^64 addresses to find your devices (that’s assuming your firewall allows inward connections) - and by the time they find an active address, it’s probably changed. Of course, where you want something to be externally accessible, that’s just a matter of configuring a fixed address and opening a corresponding firewall rule - you don’t need to configure NAT port forwarding as well as, and you’ve plenty of addresses to run multiple servers/services on the same port(s), something not easy when you’ve only one IPv4 address. > I'm not an authority on firewalls and routers, but I'm going to try > hard to pass only a very few IP addresses on my LAN, and put the Wifi > on a third network card. That’s easy enough to do. Get a switch that supports VLANs and you can segregate traffic to multiple wired segments without needing multiple cards in your server/router. > In my opinion, IOT (the Internet Of Things) is for the most part an > abomination. I don't want my thermostat on the same subnet as my LAN. Agreed there. As an aside, and not specifically in response to either of the above emails, I recommend the certification scheme run by HE at https://ipv6.he.net/certification/, and if your ISP doesn’t yet offer IPv6, then their tunnel service will provide you with good IPv6 connectivity. It’s true that there is some learning you need to do for IPv6, but this course will take you through things in steps - start with the basics and work up to the more complicated stuff. The only bit I thought was a p.i.t.a. is a stage where you have to provide ping and traceroute results to 100 different IPv6 destinations over 100 days. The hardest part if finding 100 different destinations - at the time I did it, I did some grepping of DNS server logs at work to find them ;-) Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] questions further into networking
o1bigtenor via Dng wrote: > I have been considering setting up a 'Pihole' to enhance my network here. > > Is a Pihole a useful addition into a ipv6 network or ? (As already mentioned) The Pihole works at the DNS level, so it simply blocks DNS lookups for “stuff you don’t want”. So it’s agnostic to the transport layer - IPv4 or IPv6. I can’t help thinking that one (of several) reasons for things like DNSoverHTTPS, and as I recently read on another mailing list that (at least) one of the TV streaming devices only works with the vendor’s DNS service is to bypass protections like DNS filtering/blocking. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
o1bigtenor via Dng wrote: > Not only do I want to echo mr Joel but for mr Simon. > This gives great information - - - all together AND in a fashion that > I think I may even be understanding this. Thanks, that makes it worthwhile having written it. As you might have guessed, I’m in the IPv6 is good camp. Frustratingly my ISP ran IPv6 trials several years ago but has since gone quiet - even though their parent company (a larger ISP) rolled out IPv6 by default several years ago ! > Please would you fashion perhaps 2 or three more messages for > intermediate and maybe even extend this into more of the > 'advanced' networking country. I’m not sure there’s all that much I can add. One of the problems of not using it often enough is that I’ve forgotten a lot of what I learned when I worked through the tunnelbroker certification - which BTW will (if it’s still part of the deal) will get you what must be one of the geekiest tee shirts ever created ! One thing I didn’t cover is addressing, and how they are represented. https://en.wikipedia.org/wiki/IPv6_address gives a fairly decent overview - apart from perpetuating the myth that EUI-64 addresses are still common - they were deprecated a while ago. Then I can perhaps outline what you need to do to set up your own router supporting IPv6. On the ISP end you need the appropriate interface and software. So this may be PPPoE, or direct Ethernet with one of a number of configuration protocols, or ... So the first thing to do is sort out whatever combination of bits will get you connected. One of the problems is that there are a number of different components, that can be used in different combinations - so you’ll need to find out exactly what your ISP uses/supports. This is all from memory, so can’t rule out errors :-( In my case, it was a case of using a DSL modem and running PPPoE over an ethernet link. With PPP, LCP (Link Control Protocol) will negotiate the session with the far end PPP service, then the PPP package will configure the protocols you tell it to - IPCP (IP Config Protocol) for IPv4, IPv6CP for IPv6. Checking my notes, I then had to run a DHCPv6 client to get an IPv6 delegation - in this case asking for a /56 prefix. I manually/statically configured all this with scripts for expedience (we got static IPv6 allocations) - it’s possible to automate steps using features in some of the software, which has generally advanced since I last did this. So now we should have a working IPv6 link to the ISP and an IPv6 prefix. The link may just have a link-local address (starting fe80:) or it may also have a GUA (Globally Unique Address) as well - depends on the ISP setup and your own setup. So my script then added a GUA address to the PPP interface, a route to the internet via that link, and a different GUA to the internal interface. At this point, you should have a system that can route packets between an internal device and the internet. You will want to configure an IPv6 firewall. I used Shorewall for this - it’s an amazing package. It’s still usable, but it’s time is now limited as it’s deeply entangled with iptables which is now deprecated and replaced with nftables. I imagine that at some point the iptables compatibility shim will go away and that will stop Shorewall. You now need to configure devices on that internal network. You can do it statically - but that’s a p.i.t.a. So configure and start an RA daemon. Again, as this was a trial and we had static allocations, I just put the prefix in the config file and had my script bring up radvd. This is perhaps one of the steps that would be harder to automate since you need to pick a /64 prefix out of your (hopefully) larger delegation. And you also have the ability to run multiple internal networks with different prefixes. Once you startup the RA daemon, you should see clients auto-configure and be able to use your new IPv6 service. > I am not needing ipv6 at present but likely this spring fiber optics > are happening (finally some decent speed options) and they are > in the process of moving to ipv6 likely within a year or so. I would > prefer to know at least some more before I 'need' it. Good news then - the more ISPs do IPv6 the better. The main thing to remember is that IPv4 vs IPv6 is orthogonal to the rest of the stack - the physical layer underneath (fibre, ethernet, xDSL, cable, dial-up, damp string, carrier pigeon, ...) and the session layers higher up (DNS, HTTP, SMTP, ...). Things are not completely disconnected as things need to support the differences - e.g. handling 128 bit long addresses, doing lookups as well as A, and so on. But (and not speaking as someone who’s had to deal with that), I think a lot of that is handled by the standard libraries. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
ites or ssh in. Also, I'll need to have them receive > DHCP from somewhere, and try to configure the DHCP to specific MAC > addresses. That’s one way of doing it, but can be quite inconvenient - depending on your use case. Personally, I have the WiFi inside the network, and run multiple SSIDs so different stuff can go on different networks - including having a guest network with client isolation turned on. At the moment I have a few bits of the puzzle missing, but eventually (given time and cost constraints) it’s my intention to run multiple VLANs for better segregation. For many people, having wireless laptops behave differently to wired systems would be “a problem”. Especially if you have services (printing, file shares) that use mdns to locate/use them. The reality is that there is no “right” or “wrong” way to do it - just different sets of priorities that make different topologies “better” or “worse” for different people. It really a game of finding “best” for your personal set of requirements and priorities. As I said above you can make a system really really REALLY secure - but also of no practical use ! Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] questions further into networking
o1bigtenor via Dng wrote: > When this (streaming device only works with the vendor's DNS) happens > - - - is there a way to > counter or change that particular behavior? > > (Fascinating what's all connected!!!) Obviously when you buy those closed boxes, you get what’s lent and it does what the vendor wants it to do. But with DNS, you have the option to filter the DNS packets at the firewall and re-direct them to the internal DNS server. But you also have to arrange for the replies to get re-written as well so the devices sees the replies as having come back from the same address it sent the query to. Fundamentally this needs the traffic to pass through the firewall in both directions - either because the firewall is in the traffic path, or because it’s the default router for the DNS server. There’s a lot of stuff in the Shorewall FAQs, though I guess they “lose a bit in translation” if you aren’t familiar with Shorewall and it’s config files. https://shorewall.org/FAQ.htm#faq1f Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] online purchasing (dunno - - - maybe OT)
o1bigtenor via Dng wrote: > I made a purchase from an online store - - - its a smaller entity that > covers some interesting niches - - therefore the order. > > In doing the purchase - - - noticed, using uBlockOrigin and > PrivacyBadger, that paypal 'only' has some 9 domains linked into the > transaction. Hmmm - - - that's not all - - - that's what PrivacyBadger > was picking up - - - uBlockOrigin noted that there were some 15 > domains of which it blocked some 4. Still linked were crackbook and a > bunch of ms googly's garbage. > > So I called the company to tell them that I found this concerning. > > I asked the person that I was talking to if they were into internet > privacy and security - - - very much so was the answer. So I asked him > why he needed all these domains connected. The long and short of it > was that he got quite huffy and asked me to cancel my order (and > without saying so) get lost. It is more important to him that everyone > and his dog know about his transactions that it is for him to make > transactions. I suspect it’s more a case of two things : They are using a packaged system that doesn’t make it easy to do things properly - only how the system designer things they should be done. and/or They get a lot of their business via those routes so there’s a potential financial hit if they turn off the tracking. Recently I had a case where I went to an organisation’s web site and got (IIRC) a non-complaint cookie notice. IIRC it was the sort that basically said “we use cookies” rather than “can we use cookies”. When I contacted them, they were grateful I’d done so - they’d had some work done, and because everyone internally used the site all the time, they never saw what a visitor with a “clean” browser would see. It got fixed. > I do wish there were a way of warning other customers - - - - his > website is likely a magnet for web bottom feeders and he doesn't think > its worth things about. No easy way to tell other (potential) customers. But for the business, you didn’t say what country they are in. Both Germany and France have found the use of certain Google “services” breach GDPR. Perhaps report the site for that ? I think this is going to get “interesting” for site owners ;-) https://www.theregister.com/2022/01/31/website_fine_google_fonts_gdpr/ https://www.theregister.com/2022/02/10/google_analytics_gdpr_breach/ https://www.theregister.com/2022/01/13/google_analytics_gdpr/ Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wifi problem - dhclient times out with no reply
Gregory Nowak via Dng wrote: > If I understand that you can associate with the access point through > wpa_gui, what does iwconfig(8) say? If iwconfig says the adapter is > associated with the access point, can you configure a static IP > address valid on your network, and does that work, or do you still > have no internet connection. Yes, that would narrow it down to a network problem or a DHCP problem. Assuming the network is working (can statically configure and pass traffic), then I think the next stage would be to start sniffing traffic (e.g. with wireshark, or the cmd line version, shark). Are you getting packets out, are there replies coming back, etc. Also repeat that on the DHCP server (if you can). Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] install on a raid 1 array
isk - less a bit - RAID it and use it as an LVM PV. Note the “less a bit”. If you have a raid array and a disk fails, you cannot replace the failed disk with one that’s even a single block smaller. I’ve been bitten by this in the past - with the support company sending me a replacement 9G drive that won’t work, and spending ages talking people through why one 9G disk is not the same as another 9G disk (they had to hunt around for the same model disk in the end). So I always leave a bit of space unused at the end of the disk to allow for these differences - and these days it’s unusual to be clamouring to use every last block. As an aside, back in the 90s I used to deal in Apple Macs. The disks all had unused space - so at the factory they could just mass duplicate a master copy onto the disks without having to worry about different sized disks, the image just had to be small enough to fit on the smallest disk they used for each nominal size (back then, typically a choice of 20meg, 40meg, or 80meg if you had loads of brass). Note: If you have 3 or more disks then you can pick and choose the RAID level you use. /boot is always RAID-1 so each disk holds a full copy of it. The rest you can pick and choose depending on your requirements. Generally RAID 5 gives you the most space, with more disks, RAID 6 is an option and gives you two-disk redundancy. But if your priority is performance, then striped & mirrored or mirrored & striped gives you the best performance with single disk redundancy. Once over, you had to set up mirrored pairs, and then stripe the resulting volumes together; or stripe the partitions and then mirror the two stripe sets. Yes, a bit of a PITA and only works with an even number of members ! These days, Linux RAID supports RAID-10 where it’s done automatically and (IIRC) supports an odd number of members. Not to mention, these days you can add disks to arrays dynamically - it used to be “fun" finding the disk space to copy all your data to while you rebuilt RAID arrays from scratch. Not to mention the out of hours tedium of waiting for it to copy, and the feeling of trepidation (I hope the disk I’ve copied it all to it OK ...) when you go and nuke your existing array in order to build a new larger one. * I **ALWAYS** have a separate /var. Trust me, if you have (e.g.) a runaway log and it fills the filesystem, then you will thank yourself for restricting it to /var. After that, it’s all down to what the system is for. E.g. for a mail server I’ll have a separate /var/mail; for a web server, a separate filesystem for that (wherever it gets put); and so on; perhaps a filesystem for your database(s). If it’s a system you “work on”, then you might want a separate /home for users’ home directories. Again, protects the system to a certain extent against users going mad creating big files. You can do a lot of this with disk quotas these days, but separating filesystems is a powerful tool. And with LVM it’s generally fairly easy to resize the filesystems if you don’t get it right first time. Now, back to how to install it ! You’ll need to go into the custom partitioner, and from there, you can partition the disks manually - don’t forget to set the partition types. When you’ve partitioned the disks (and written the partitions out to disk), you need to go into the raid configurator and create your RAID array(s). When you come out of the RAID config, you should then see the array(s) listed along with the various partitions. You can now go into the LVM manager and configure LVM volume group(s) (VGs), and then your logical volumes (LVs). Again, when you exit the LVM config, you should see the LVs listed. Make sure each partition/array/LV is set appropriately - whether to format it, where to mount it, and so on. This is the key bit to getting the different bits of the system where you want them. From memory, I’ve found that it will then format the filesystems, mount then in the right places, and install the system on it. Your mdadm and lvm configs should be correctly configured in your installed system. I think by default in only does a grub-install on one disk, so when you’ve booted your new system, do this for each disk that’s part of your /boot array - it’s “annoying” to find (when a disk fails) that the others disks don’t have the first stage boot loader installed :( Hope this helps, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] starting mysql in background ?
Radisson via Dng wrote: > i would like to start my mysqld 8.0 in background because it takes > several minutes to start. Under what init/process manger setup ? If under SysVInit, then I would suggest you could simply modify the relevant init scripts to not wait for the process to fully start - i.e. just return success as soon as it looks like it is starting normally. But you’ll also need to modify anything that depends on mysql such that it will wait for it to be available rather than just the init script having exited normally. There is an argument that the correct way to start processes is to simply start them all at once (zero attempt at sequencing) - and have the beginning of each script (or other config mechanism) be a “wait until my prerequisites (however I define them) to be available” step. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] starting mysql in background ?
Radisson via Dng wrote: > i use sysv-init with a simple start script in init.d. > in the end the script starts mysqld_safe in background and > waits for a pid. (yes i could remove that but i do not know the side > effects) The side effect of removing that wait for a PID is that any other service that depends on the database will be started before the database is actually running. If you don’t actually have any other services that depend on the database then it’s not a problem - you’ll just have to know not to try and run user programs needing it until it’s up. If you do have such services, then you’d need to delay their startup - and then you’re back to the system sitting there waiting for the database to be running. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] install on a raid 1 array
nted (with the irrelevant bits omitted). Yeah I’m a bit old school and still use ext3 ! Now, back to your specific setup. I suspect you really want your efi partition to be a plain partition - so that’ll be sda1. I’d create a matching sdb1 partition - and possibly clone the contents of /efi onto it at some point so you have a working boot setup from sdb. Personally I’d keep to having a separate array for /boot - so that’ll be sda2 & sdb2. Create those two, then create an md array using them, then create a filesystem on it. Then you can either continue creating partition pairs, creating a raid array on each pair, and putting a filesystem on each array - but at some point you’ll hit limits on creating partitions. Or you can just create a partition for “the rest of the disk” (minus a little to allow for a replacement disk not being identical in size), create an array across the pair of partitions (sda3 & sdb3), then assign the array as an LVM PV, create an LVM VG using that PV, and finally create the LVM LVs you want for each filesystem - using LVM is more flexible as it’s easy to resize an LV. For /home, partition the disks (sdc & sdd) using the whole disk. Put the two partitions (sdc1 and sdd1) into an array. Put a filesystem on the array. There are two ways to do this with the Debian installer (from memory). Using the installer, do the partitioning but at this stage specify to do nothing with each partition (apart from efi, I don’t use such new fangled stuff so I don’t know what it does by default with that). Exit the partitioner and it’ll ask if you want to do the partitioning - say yes. Now go into the raid array option in the partitioner and create the arrays - when prompted, create the arrays and exit the raid setup. The partitioner should now show you some physical partitions as being in raid arrays, plus the raid arrays. Go into the LVM setup section, create an LVM VG and use the array previously created (sda3 & sdb3 in the above example) for it’s single PV. Then create LVs as required. You can configure the /boot array as “create filesystem, mount on /boot”. If you have created any more arrays (e.g. for /), then configure these accordingly. For /home, use the array containing sdc1 & sdd1. Similarly, configure each LVM LV. You should now see “something” for each filesystem you want - the volume used will be either a partition (/efi), an array (/boot, possibly /), or an LV (swap, /var, ...). Now, when you exit the partitioner, it’ll create all the filesystems, and mount them all on the target directory it uses for the installation. As an alternative to using the installer, IIRC you can switch to another console and it’ll give you a root shell. You can now do all the above steps manually using the command line - partition the disks, create the arrays, create the LVM VG & LVs, create the filesystems. When you with back to the installer, you may have to exit the partitioner tool and re-enter it to see all the now existing partitions, arrays, LVs, and filesystems. Flag each filesystem according to where you want it mounted, but keep the exiting filesystem. When you exit the partitioner you’ll be at the same step as doing it all via the installer. In either case, you can switch to another console and see what’s mounted where - if there’s something wrong then go back and correct it now. Can I tell you what the commands are to create an MD array ? Can I - I do it so infrequently that I have to look it up each time :-( “man” is your friend, along with “md —help”. Hendrik Boom wrote: > I set up a separate RAID 1 pair for /boot. > > I don' know if it is necessary now, but there's an older mdadm [artition > format where the RAID signature is placed at the end of th partition. > > I specified this older format when I reated the RAID pair for /boot. > > So when I boot, there's no problem finding the boot partition and reading it, > because the important stuff that's used at boot time (i'e', the file system) > is found at the start of the partition. And it doesn't matter which of the > two copies I boot from becuase they are identical. All this booting is done > before RAID assembly. If one of the disks is missing because of hardware > failute, it just boots from the other. It’s my understanding that GRUB now understands both md arrays and LVM - so you can use the later partition format for the array. But as you point out, if you use the older format (which only puts it’s metadata right at the end of the array) then something that doesn’t understand raid will just see two identical partitions with the same contents. Regards, Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] do I need drivers for
Antony Stone wrote: > PS: Just in case you wonder "hm, sdv is awfully close to sdz - what happens > next?", the answer is simply that the standard Linux kernel then moves on to > device names /dev/sdaa, /dev/sdab, etc... > > I'm not sure where the current limit of device names is, but I don't think > you'll be able to reach it with any hardware means of connecting drives (you > might manage it at a push with iSCSI devies etc). Ooh, a few multi-port cards and then some port expanders. Backblaze are up to 60 drives in a box ! https://www.backblaze.com/blog/open-source-data-storage-server/ Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] IPv6 for dummies by a dummy (was: Configuring ethernet port for IPv6)
Following up from this old thread, over on an IETF list I’ve come across this resource for learning IPv6. https://afrinic.academy/ I’ve not looked at the content or quality - but the headings seem logical and it’s free. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
> It seems to me that it's good to have shim programs that satisfy > dependencies of apps on systemd, each shim performing some systemd > function. Here's why: > > Suppose there are 10,000 application programs (apps) for Linux, > and their developers foolishly insert dependencies on systemd. > > If Devuan developers write 50 simple shims to fulfill those > dependencies, then Devuan users can run those 10,000 apps > as they are, directly from the Debian repos. And when the > apps are updated, they will still run. As pointed out already, unless the systemd calls are not actually doing anything useful to the operation of the program then replacing each call with a "null operation" will break the program. But, IMO there is a more important philosophical reason not to do it. If it were technically possible to create all these shims that would "do nothing but magically still let programs work", by doing it that way you have "legitimised" the use of those systemd calls. As in, "use as many as you like, it doesn't actually matter". If Devuan can get to the point where the devs that are "blindly going down the systemd alley"* want to get on board, without these shims there is a clear message - fix your code or it can't be installed. * I'm sure some feel they are using systemd calls for a good reason. In many cases there may well be merit in using them when available. As an example, I tried to upgrade one of my Wheezy systems to Jessie with *systemd* pinned as not installable. It took a bit of messing around figuring out what the broken dependencies were, and in the end I only had ONE single package that I needed and which wouldn't install - clamav-daemon (the other clamav* packages were fine, just not that individual one). In response to my messages on the clamav mailing list and bug report, it turns out that they only make ONE call to libsystemd during startup and then never use it again, and it's not even an essential call - but no, it would be a "waste of CPU cycles" to do a "if exists libsystemd0 then call ..." I assume it's not considered a waste of cycles to maintain a separate package for Wheezy security updates ! If you provide a shim, then you legitimise this sort of behaviour. Which would you prefer : a clamav-daemon package with a dependency on a "fake" libsystemd0, or a clamav-daemon package without any systemd dependency ? If you legitimise using shims, then the same people that see no reason to not hard-depend on libsystemd0 will bring you a package with a hard-depends on fake-libsystemd0. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
Rainer Weikusat wrote: > ClamAV claims to support FreeBSD, OpenBSD, NetBSD, Solaris, OpenVMS, > Slackware and Windows, all of which certainly don't have systemd. I've > just cloned the current development repository and build it on Wheezy > using a plain > > ./configure > make > > which worked without issues and this system is certainly systemd-free, > too. Which makes it even more non-sensical to make it have systemd dependencies. > Could perhaps provide some kind of link illustrating what you were > referring to? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789283 And from http://lists.clamav.net/pipermail/clamav-users/2015-June/001604.html > BTW, since I'm the primary clamav maintainer in Debian, guess how much action > your report is going to get. As you've pointed out, this is a package widely used across various OSs, and is still officially supported in Wheezy through security updates. But the Debian Jessie package hard depends on libsystemd0. Now I know some will call me paranoid, but if you're going to allow various libraries, then you are allowing part of the code that people are complaining about. I'm not able to go and examine the code, but I've seen enough of what systemd does and how it's coded to know I don't want it on servers I'm responsible for keeping running. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
T.J. Duchene wrote: > I used Debian Sid recently, with the apparent ability to boot > using either System 5 or Systemd via Grub. The choice seems clear to me > that Devuan could minimize upsteam maintenance by looking at that. The problem is not which init system to use - SystemD is not just an init system. Even if you use Sys5 init, there are a lot of packages that require parts of SystemD to install/work - so being able to boot with Sys5 init is a bit of a red herring really. On 15 Aug 2015, at 01:26, Steve Litt wrote: > Oh, you wouldn't want to do that. Contrary to what I wrote in another > thread about "the perfect is the enemy of the good", if *I* were in > charge of decontamination, I'd throw out whole subsystems. Gnome gone. > KDE gone. Xfce gone. Networkmanager gone. Gimp gone if it gets all > systemd on us. Which really leads on to one of the "hard choices" facing Devuan. If you don't have the packages people need to run, then they can't run Devuan. And if those needed packages have been modified to need SystemD then it needs work to re-convert them. I guess a look at Debian PopCon might give some ideas which packages are being used - and hence where to spend limited dev resources. Though I suppose you could decide to ignore the GUI packages to stat with - there's a large user base (like myself) who run headless servers and so really don't care about any of the packages in that list ! Long term, you could try and get the GUI stuff in - but I suspect that's going to get harder and harder over time as the Japanese Knotweed of the software world gets a deeper hold. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
Stephanie Daugherty wrote: > They did, but out of all this design by committee, hidden between all the > political bullshit and bikeshedding, they also created the most brilliant, > most comprehensive set of standards for quality control, package uniformity, > license auditing, and of course. the most robust dependency management, at > least among binary distributions. > > More importantly than that, they backed these standards up with automated > tools that are nearly as robust as the standards themselves. You don't see > packages interfering with one another very often in the Debian world, because > this is caught right away by scripts that check that every file installed by > a package, or automatically created by that package belongs to EXACTLY ONE > package, otherwise all the packages have to use some approved mechanism to > cooperate. You also see this effort it in difficult to configure packages > that set themselves up and work out of the box, and in the modularized > configuration that's common to many packages. > > Most importantly, this rigid attention to detail is why for more than a > decade now, in place upgrades have been fully supported, officially > recommended and for the most part, Just Work(tm(. It used to be said, back in > the day that the installer was still horrible, "thank god you only ever have > to see it once" That's how I see it too - I've been using Debian by choice for a lot of years - in fact, the only systems I run that aren't debian are where I've used a "packaged" setup, specifically I have a couple of PBX "appliances" which only support (at the time they were built) being setup on Centos. On 15 Aug 2015, at 21:33, Laurent Bercot wrote: > And their package management features: > > - no way to have several versions of the same package installed on > your machine > - no atomic upgrades for single binary packages: if you have stuff > running during an upgrade, things can break. > - no possibility to rollback. The rollback is a bit of a pain. In spite of the quality control, I have had one or two issues in the past where an upgrade has broken a combination of stuff - as in X runs on language Y and uses Z for some of it's functions, but after an upgrade it "doesn't work" and then have to start manually installing older versions of X, Y, and Z to figure out which combination work. > I'm sure there's a lot of good to say about the way Debian does > things, but quality of their package management isn't a part of it. > When you're running production servers and need reliability when > upgrading software, you just can't use Debian. I've found it pretty reliable - certainly not as bad as certain commercial ecosystems I have dealings with. My expectations of "problems" during upgrades is less with my Debian systems than it is with anything else. That's not to say I've not had problems. Hendrik Boom wrote: > THe way I heard the story, in the ncient days when Apple was choosing > the kernel for OS X, they were originally planning to use Linux, but > they changed their mind for copyright reasons. THey didn't want to risk > any of their proprietary software becoming free software because of > GPL contagion. > > The BSD licence allowed them to do what they wanted. You do realise that they do in fact use a lot of GPL software don't you ? In fact they have contributed some very useful software back into the community under GPL. I'm more inclined to think they just decided the BSD kernel was more suitable to their needs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan and upstream
Go Linux wrote: > I once investigated helping a friend use some open source software on her > Mac. A program that was free (gratis) in the Linux community was available in > the Apple app store for $30! That really pissed me off and soured me even > more on Apple than before (if that was possible). If ti was GPL then it would have been available free of charge if you looked in the right place. Contrary to some opinions, Apple do behave themselves in this respect. Did you try Fink or Macports ? http://www.finkproject.org https://www.macports.org I've come across other cases where "free" software has been available in a store for real money. In my case I have a couple of packages on my Android phone where I paid for them through the Google store although I could have got them free elsewhere - just for the convenience factor, plus it's a source of a small amount of income for the projects concerned. But this is off-topic for here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd Shims
T.J. Duchene wrote: > I am neither an advocate for systemd nor am I an advocate for > System 5. Both have issues and are basically different approaches to the > same > problem. If that were the case then there would be no arguments, and probably no Devuan. If *all* SystemD was was an init system then no problem. But it is not "just another init system" - as already done to death, it's like Japanese Knotweed spreading it's roots through everything. I don't know the people heading it, only the things that have been said. However, I've seen enough from the codebase to convince me it's not a project that should be let anywhere near a production server. Perhaps if people stopped saying it's a choice between Sys5 and SystemD as an init system then there's be more clarity about the argument. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [arthur.ma...@internode.on.net: Re: Interesting comment from a kernel developer]
Haines Brown wrote: > Just a side note. I installed Sid on a x250 Thinkpad and then replaced > systemd with sysVinit. Things seem to be working just fine, although > admittedly I didn't install any desktop environment. Did you also try removing the rest of SystemD ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [arthur.ma...@internode.on.net: Re: Interesting comment from a kernel developer]
Haines Brown wrote: > No. I installed sysvinit-core sysvinit sysvinit-utils, rebooted, and > then did: > > # apt-get remove --purge --auto-remove systemd > > # echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: \ > -1' >> /etc/apt/preferences.d/systemd So you still have parts of Systemd installed then. dpkg -l '*systemd*' Try removing libsystemd0 and see what happens ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Offtopic: pointed messages?
Mitt wrote: > I noticed that my messages are not pointed to those who they are sent to. See > image > https://imgur.com/J4UaT7D Are you referring to the fact that it's not shown in "it's place in the tree" like the rest of the messages ? If so, then that's because your mails don't contain In-Reply-To: or References: headers. Without those, the archive has to use the subject line to thread messages, and it can't "link" them because it's now way of knowing which other message your's was in reply to. Interestingly, while looking through my inbox for this list, I see a few other users with the same issue. The flip side is that when using an MUA that does correctly insert such headers, people who start a new thread by hitting reply to an existing message and changing the subject result in two thread being mingled in some archives - the References: refers to a message in the other thread, so the messages starting the new thread get inserted in "their place in teh tree" of that old thread. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] remove systemd for the love of Yog-Sothoth already
Svante Signell wrote: > See above, the DNG mailing list is mostly full of discussions and not > much actions, except for from a few people. That is the impression I'd got as well. Now I'll preface the next bit with ... this is not meant to be an insult or criticism, so please don't take it that way. It's intended to be constructive suggestions from the POV of a sysadmin looking to avoid SystemD - a refugee from Debian Jessie if you like. I'll add that my programming skills these days don't extend much beyond Bash scripting and some SQL. And also add that as a fairly new arrival here, I'm aware that some of the "bits I perceive as missing" may actually be there but I haven't found them yet. ISTM that the priorities need to be : 1) Get something working ! That means having the systems in place so that the target audience can get a system up and running without too much hassle. And also having all the needed files/packages present. If in the short term that means having SystemD (or bits of it) then so be it - IMO it's better to have something that works, and a clear strategy for disinfecting it, than to have nothing at all. I've seen some threads regarding installation issues, so I can see that there is both progress and work still to do there. 2) Get devs on board. As hit on by Svante, that means having the processes in place so that those that are capable and willing to support the project can do so - ie having the systems in place to manage and build the packages. Just in this thread I've seen evidence that at least one person has their own repository of "fixed" packages. That's great, but for production servers, the PHBs out there expect to see "official" packages that have gone through the projects QA process at least. PHBs tend to get nervous about using packages that have some similarities with the electronic version of "I got it from a bloke in the pub". 2) Get users on board. That needs 1 and 2. 4) Properly disinfect the remnants of SystemD out. Now I've refused to upgrade to Debian Jessie (I tested one server, rolled it back to a backup) because packages I need have added gratuitous SystemD dependencies. The weightings to that decision change significantly when it's "SystemD is there but we're working really hard to get rid of it" vs "shut up it's here to stay". Notice that there's 2off number 2 there ? I think there's a chicken and egg problem - and a limited time window. Without the user base, there's perhaps less appeal for devs; without the devs, there's the risk of not providing a compelling "product" for the users. If it takes too long, refugees from Debian+SystemD will come along enticed by the references in the trade comics/blogs etc - and if there's nothing useful to see then are likely to get disillusioned and wander off. How many times have you seen something announced, there's a lot of buzz (and hype - though not necessarily from the project), and then when reality sinks in it all sort of deflates as potential users find out it "doesn't deliver". As to timescale, at present Wheezy is in support - and so security updates should still come through. C.f. clamav-daemon has been updated for Wheezy without the libsystemd0 dependency it has in Jessie. So to a large extent I (as a sysadmin) have some legitimate reason why I can hold off "upgrading" to Jessie. As soon as Jessie+1 is released, then Wheezy becomes unsupported. At that point, it's hard(er) to argue against having to upgrade. So I'd say ... Yes, remove SystemD please. But it's not the first thing that needs to happen. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide
Nate Bargmann wrote: > I'll add my voice to the chorus objecting to the idea that removal of > systemd is for servers only. I don't think anyone has suggested it's for servers only. But, there is an argument for picking the low hanging fruit - and that means trying to do the "easy" bits first. I've not really followed it in detail, but from what I've read it does seem that the desktop environments have been the most tightly bound to systemd. IMO it makes sense to try and get a "non desktop" system sorted, and then tackle the harder problem of getting the desktop stuff cleansed. > Right now with Debian Jessie systemd must be installed to make the > desktop anywhere near functional, but that is a result of packaging > decisions by Debian ... I don't think it's so much a packaging decision by Debian, more a case of what the upstream devs have done. The Debian decision was (AIUI) "we don't have the resources to remove the crap" - not a decision to add it, just a realisation that the project couldn't remove it with the time and resources available. I did note some rather naive suggestions that somehow it would be possible to remove it later. I'd be surprised if the resources increased, and it'll be a lot harder to remove stuff now they've allowed packagers to add "gratuitous" systemd dependencies. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] wpa_supplicant/ifup integration documentation
Didier Kryn wrote: > I am pretty sure there are very few cases where a wifi connection needs a > static IP config. For the vast majority of cases, the config is dynamic and > one single id_str is enough for all; doing otherwise would bloat the > interfaces file for the sole sake of this description. That makes sense - provided that it's still possible to manually add entries which fall into that other 1%. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] the devil is in the details.
Rainer Weikusat wrote: > That's a long rant about 'systemd architecture' with an inflammatory > subject someone posted to the systemd devel list. It didn't receive any > replies more noteworthy than the original text which is 'hardly > surprising'. Ah, I'm not alone in thinking that then - should I feel "a bit sick" finding myself agreeing with system-d supporters ? But one thing I did pick up on, one of the reasons given for not having any subdivision was a desire to not have to have documented and stable APIs. I find that "a tad off-putting" because in the projects I used to work in (many many years ago, working as a very junior engineer in a shipyard supplying the navy with bespoke vessels) that would have been one of the earliest parts to be nailed down - split the "blob" into small parts, each doing something understandable and testable, and have them all communicating via fixed* and documented interfaces. * Fixed, as in "can be changed if it has to, but it'll need all the change control that goes with it". Reading that the ability to change internal APIs on a whim is seen as a positive attribute suggests to me that this isn't something that's been designed before it's been built. I know our methods weren't what you might call "agile", but they were intended to give some expectation of reliability. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Rainer Weikusat wrote: > ... or the fact that apache on the box I'm presently > using 'depends' on bind and syslog. Well in the general case*, those are not unreasonable dependencies. In the general case*, Apache needs** DNS resolution during startup, and it rather makes sense** if it's able to log stuff while it's starting up. * And all software builds/packaging is a compromise. The package needs to support the general case, and a wide variety of not quite so general use cases. If your use case doesn't have any dependency between Apache and DNS then you are free to remove that - I know it's not exactly hard to do with Sysinit. ** Again, need is a relative term. In my experience, Apache will start "just fine" without DNS (but it does depend a little on your config), but not having DNS may mean it can't determine some values which are good for it to have. You can remove that dependency if it's not applicable to you - but for some it's "important" and it makes sense for the default to work for "most people". It doesn't absolutely need to use syslog, and it doesn't absolutely need to log stuff during startup - but in the general case it's going to cause less complaints if it's able to log stuff using syslog while starting up - if you're not bothered then you can easily change that too. The thing is, it really does not matter what decision you make - there will be a vocal minority for whom that is "completely wrong, how on earth could you do that". I've witnessed 'discussions' where someone building low footprint systems complain that (in that case, I think it was Debian) installed loads of stuff they didn't want by default, and that packages weren't modular enough to allow them to leave out the bits they didn't want. He just couldn't see that a) the default package list needs to be a reasonable compromise between installing stuff most people commonly need and space, and that b) he could easily change things himself if that default wasn't suitable - he just considered the Debian guys to be "wrong" for not supporting his exact use case by default. So how about a bit less complaining, and a bit more rejoicing that we have a lot more choice and flexibility than (say) Windows users ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
KatolaZ wrote: > Just please try to > avoid falling in the same "everybody needs to boot-up in 12 seconds > because high availability requires so" rhetoric championed by > systemd-fanboys. More to the point, I'd rather have reliability over speed any day. If the system boots reliably in 2 minutes vs "less deterministically" in one then I'll take the 2 minutes. But one trick that the desktop vendors are doing, and I suspect SystemD are copying, is to "fake" a fast boot. By prioritising certain bits, you get the illusion of a fast boot (getting to draw a desktop) - but if you try and actually do anything straight away it "doesn't work" while all those services are starting in the background. I've noticed Win10 is particularly aggressive at this since "time to a desktop" seems to be such a key metric these days. But, if you are going to boot slowly and methodically, it helps if there's signs of progress. There's nothing that gets people impatient better than something that appears to be taking a long time "doing nothing" ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] Nostalgia (Was: s6-rc, a s6-based service manager for Unix systems)
KatolaZ wrote: > Agree! That's why I would warmly suggest mobile devices producers to > include a pluggable nixie-tubes display like this: > > http://ad7zj.net/kd7lmo/images/ground_nixie_front.jpg Metaphorical "hands up" - how many of us went "gosh, how long is it since I saw one of those in the front of some kit ?" (or something similar) Is it one of those "if you remember that, you must be getting old" technologies ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [announce] s6-rc, a s6-based service manager for Unix systems
Laurent Bercot wrote: > On 25/09/2015 09:05, Simon Hobson wrote: >> More to the point, I'd rather have reliability over speed any day. > > How about you get both? Well yes, that's better still. > The dichotomy is a false one. People believe they can't have both > because init systems have never been done right so far, and always > forced them to choose between one and the other. This is what > I'm aiming to change. No less. Well yes. I tend to be happy to stick with sysv-init because a) I know how it works, and b) it's easy enough to diagnose issues, and c) it's "good enough" for my needs. Yeah, it's not perfect, but *for my needs* I can easily work around those imperfections. What you are doing does sound good, guess I should really add it to my list of stuff I'll probably not find time to look into :-( >> But one trick that the desktop vendors are doing, and I suspect >> SystemD are copying, is to "fake" a fast boot. By prioritising >> certain bits, you get the illusion of a fast boot > > Yes. I have no idea how Windows does it, or how other OSes do it, Windows and MacOS both prioritise those tasks needed to get a desktop picture (or login prompt) on the screen - as that gives the illusion of fast boot time. That the system is still far from ready is evidenced by a) the time it takes to load all the applications I am usually running, and b) the disk and CPU activity going on for quite a while afterwards. IME the fast boot is largely illusionary anyway - the disk I/O and CPU utilisation makes the whole system "sluggish" so it's not worth trying to do anything until all the background stuff is at least well past it's peak ! Rainer Weikusat wrote: >> * anything that uses the syslog should start after the syslog. > > That's the same misunderstanding already shown elsewhere: Starting > syslog at time X and starting syslog-user at time Y, Y > X, Y - X being > 'very small', does not guarantee syslog will already be available at > time Y and neither that it will still be available provided it became > available in the time interval between X and Y. That all hinges around what is meant by "start service A". If "start service" means nothing more than "kick off a process that'll run it" then you are completely correct. On the other hand, if "start service" actually means a process which is only deemed to be complete when it's running and ready to go to work then that's a different matter. Of course, regardless of what system or definitions you use - if a service then dies then you have a problem. IMO, "it might die at some indeterminate time" isn't an excuse for not trying to get the "start stuff up" part right. Taking the example of syslog - if it dies (regardless of when, whether it's seconds or days after system start) then you are going to lose logging. You can try and manage that (spot the problem and deal with it automatically), but short of predicting the failure in advance, there will always be a window during which logging can be lost. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Steve Litt wrote: >> The whole point of having 'an operating system' >> is that it provides an abstract interface userspace software can use >> to interact with the physical components of a different computer >> according to the functions they're supposed to be provide, regardless >> of the way this particular computer happens to be assembled. > > Does anyone else agree with me that in the preceding sentence Rainer > encapsulated the entire philosophy of people desiring simple and > logical software? Rainer, can I quote your preceding sentence elsewhere? It seems a good summary to me. >> Considering this, encoding details of the bus layout and current bus >> configuration in network interface names is just profoundly stupid. > > I thought it was stupid for other reasons, but now that you mention it, > yeah, naming it after the particular slot into which it's plugged in is > stupid, and if you take the box apart and move things around, you can > break your OS. Unfortunately, I think this is one of those areas with no right answer - only different levels of suckiness. Constraining "the system" to always loads drivers in a specific order, and hence not randomly rename interfaces at boot time is wrong. Using stupidly long/complicated device names based on physical location is wrong. Doubly wrong when location can be highly variable (as in USB devices)* Using stupidly long/complicated device names incorporating the device serial number (or MAC) is wrong. Using persistent rules files (as with Udev) is wrong. However, I am happy with the way Udev does it. Booting a "new" system results in an initially random device ordering, but once it's created a rules file the devices stay stable until "something changes". When changing hardware, or shifting the image to new hardware, new devices get created and the admin needs to "fix" it - but TBH it's not hard to do. IMO - the sort of person who cannot edit the system created rules file is also not likely to be running the sort of system where it matters. Eg, they are likely to be the sort of use who plugs a cable into a hole in the back of the computer, and "the system" takes care of enabling it and getting addresses via DHCP/autoconf - the user doesn't care if it's eth0, eth57, flurbleport29, or anything else as long as "the network works". If for some reason they replace a network card, it's not likely to matter to them that eth0 is now called eth1 - as long as "it just works". I don't tend to use ethn anyway on bare metal systems - they all have Udev rules to set meaningful names like ethext, ethlan, ethint, and so on. Different on my Xen VMs (Debian [Sarge** ... Wheezy] as out of the box there doesn't seem to be a Udev rules file created and it's never bugged me enough to figure out why ! * I've only hearsay evidence from the screams of colleagues, but it seems that some Windows stuff (in this context, setting up automated backups) is sensitive to which port the disk is plugged into. As in, if the user plugs the backup disk into the wrong USB port, it gets a different drive letter (how 20th century !) and the backup (which uses drive letter and not anything more sensible) fails. ** Yup. still got one of those running ! There is something of a parallel with filesystems/disks - where the results of "getting it wrong" are more significant. I recall back when I had "a bit less experience" and the problem was fairly new, having issues with a system where disks came up in random order during boot (two different controllers). Now I generally use disk (filesystem) labels - though it's "annoying" that Debian doesn't support filesystem labels for Grub - which have the advantage of having their own persistent storage attached to the device, but the same problems when moving things around. It certainly needs a little care when identifying disks/filesystems by label in Xen VM configs. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC: was s6-rc, a s6-based service manager for Unix systems
Timo Buhrmester wrote: > Probably because people don't want this behavior. Auto-respawn only > makes sense when you're "relying" on buggy software you already expect > to blow up, *and* are unwilling to debug it. "Try turning it off > and on again", "A restart will fix it" is the Windows-way... > > In all other cases (I can think of), respawning a crashed service > is exactly *not* what I want to happen (it could have crashed because > it was exploited, providing the attacker with unlimited attempts). > Or it could have crashed because there's an environmental problem > that isn't directly under the program's control, in which case > restarting it would just be pointless, because it likely can't start > at all. > Bonus points if the logs of the initial problem get rotated away due to > excessive retrying, or the core dump of the initial crash gets > overwritten... I think that's one of those "every admin will have their own ideas" things - and it'll vary with the system and what it's doing. You're right, that in many cases it's best to just leave it dead and let the admin deal with it. On the other hand, I've known even the best software occasionally quit for some random (and usually transient) reason. And then there's the point you've raised - what if it's an exploit ? Well on the one hand, you let it stay down until you've determined that and fixed it. On the other hand, it means the attacker only has to hit once to cause a denial of service that lasts until some admin can deal with it - it may be better to have the service pop back up and provide some reduced quality of service than to provide no service at all. That is a question for those who know what the service is, and what all the different factors are. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] netman: support for wlan1, wlan2, ... and eth1, eth2, .... and new systemd's naming scheme
tilt! wrote: > I think the entire issue "how do i scan for available networks" is badly > implemented in wicd *and* in Windows WiFi Connections (which are two WiFi > connection assistants i know from practice). For completeness, this is how OS X (version 10.8) does it. If using the WiFi icon on the menubar (the quickest and easiest way to do it), the menu has (from the top) : - WiFI: On, which periodically changes to WiFi: Looking for networks... - Turn WiFi Off --- Then a list of visible WiFi SSIDs which updates dynamically. Each entry has a "padlock" icon if secured, and a signal strength icon. If already connected to a network, there's a "tick" icon before it's name. --- - Join Other Network... which goes to a dialog where you can type in an SSID and select security options (and which has a "Show Networks" button which brings up another dialog with a list of SSIDs. - Create Network... which allows the creation of an ad-hoc network - Open Network Preferences which does just that. If doing it though the preferences panel, there a panel with status at the top (shows connected network, IP address, and a button to turn WiFi off (or on if it's off). Below that is a drop down menu of SSID which more or less mirrors the menu bar menu. An Advanced button brings up a dialog that (amongst other things) shows a list of all remembered networks, which can be ordered to set the priorities for which network to join if there is more than one visible. Something to be aware of. Over on another forum (IIRC) there was a discussion related to viewing networks. The person concerned lives in Singapore and their housing density is such that the list can be hundreds of networks long - in fact, so long that before it's finished displaying and the user has chance to select their network, it's started scanning again ! Worst I've personally experienced was when sent to Monaco (really, really not as glamorous as it sounds !), where I could see something like 40 SSIDs - and of course, a handful of them were on "wrong" channels so as to maximise interference to other networks (eg on Ch3 so it overlaps Ch1 and Ch6). So whatever system is built, it needs to allow for those unfortunate people with massive SSID lists to deal with. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
poitr pogo wrote: > > I thought it was stupid for other reasons, but now that you mention it, > > > yeah, naming it after the particular slot into which it's plugged in is > > stupid, and if you take the box apart and move things around, you can > > break your OS. > > > > no. it is not stupid. it is the most reasonable way. one can replace a part > and do not have to touch any system config. And the flip side is that you can't move anything without the name changing. Plug the USB-[ethernet|wifi] adapter into a different orifice and it's now got a different name. Move an ethernet card because you want that slot for something different and it's now got a different name. > device by manufactuter name or model name or serial. this is stupid. No more or less stupid than by physical location. Eg, taking the above mentioned USB adapter - if you use it's serial number then it keeps it's name regardless of which socket it's plugged into, vs changing name depending on where it's plugged in. As I've mentioned before, I know that the Windows guys at work have had the problem where the customer/end user plugs the backup drive into a different USB port and the backups fail. So I believe we normally tell them to leave the cable attached to the computer. Lets face it - there is no "right" answer to this other than a system with enough intelligence to read the user/admin's mind and work out what they intend to happen - and I think we're a bit off that yet ! Looking back, I think I've "moved" something at least as often as I've replaced it with a different something in the same location - probably more in fact. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
Hendrik Boom wrote: > Can we agree that ww shouldnn't have to change our configurations if we > do not change anything in the hardware? That would be a reasonable base requirement. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming (was: What can I do after netman?)
k...@aspodata.se wrote: >> This is why you use UUID= or LABEL= in /etc/fstab. +1 for that. I use LABEL=, but it's annoying that Debian's grub-install doesn't handle that (it only has options for device name or UUID). > Let's face it, thoose other names of the device is just symlinks Does that really matter ? If someone is needing to work at the device level, they they should know how to determine the device name. But from the "system doesn't randomly break itself" POV it's one way to deal with the issue. > ... after all, fstab and /dev/-names are just > for the user space. The kernel mostly only cares about the maj/min > numbers, or am I wrong? That's the case all along. The question is how to map those node IDs to something human readable. > What happens when you unplug your root fs, wait a few seconds till > the kernel gives up and then plug it in again ? I would expect the system to die horribly if you do that - regardless of how you name things ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Purpose of an OS: was network device naming
Didier Kryn wrote: > Out of curiosity, why are the virtual Ethernet given random addresses? Well they have to have something ! For Xen, they've registered an OUI to get a block of MAC addresses to use. If you don't specify teh MAC address in the VM config then it'll pick one at random, but you can specify a specific address (that's what I do - derived from the IP address) and that will be used. If you specify an address then the machine will behave as though it has a fixed address - but obviously you have to manage the assignment of addresses and ensure uniqueness within your own network. "Interesting" things happen if you get this wrong and start two VMs with the same MAC address :-( I suppose the alternative would be for the virtualisation manager to keep some state - assign random addresses to new VMs, but then store those assignments to make them sticky - only changing them if something else (eg a VM hosted on another host) has taken the same one. Windows HyperV is the same. VMs change MAC addresses every time they are restarted - the difference is that my colleagues can't be bothered setting fixed ones. I know this as I have Nagios setup to monitor the network for rogue devices (or duplicated IP addresses) - and I have to update it's config every time one of the Windows VMs is restarted. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Nnetwork device naming: was Purpose of an OS
Didier Kryn wrote:
> There seems to be a new fashion to install config files half in some random
> place and the rest in /etc, with precedence in /etc in case of duplication?
> Xorg does the same, with defaults sparsed between /usr/share/X11 and /etc/X11.
There are good reasons for doing it that way - a few packages I use are like
that. It means the packages can ship with large and complete config files in
/usr/share which can be updated when the package is updated. The user/admin
then provides local config in /etc which overrides only those options needed
for the local install. If the package supplied defaults are reasonably sane,
then it means the local config file can be fairly small.
It (mostly) gets round the problem of sticking a big config file in /etc, the
user/admin edits that, and then when the package is upgraded, the user/admin
has to go through all the differences and either miss out on new stuff in the
config file or redo all the localisation by updating the new config file. IMO
that's one of the biggest headaches of upgrades - going through config files
side by side deciding how best to handle it.
I guess it's functionally no different to having a /etc/${package}/config and
/etc/${package}/config.local
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] About the experimental live DVD
Godefridus Daalmans wrote: > We all need to begin somewhere. > > Not all of us are experienced enough in the areas we need to learn to make > Devuan thrive. Indeed, and I feel a bit "leechish" not being able to put anything practical in - I know next to nothing about packaging and all that. I wouldn't even know where to start looking to do what you've done ! > A large task like "make an improved Devuan fork of a Debian package" or "make > a better udev" or "split dbus in three" is best done in little steps Indeed. And I see it as a huge task. Clearly at the moment there are quite knowledgable people fixing the things that matter to them, and trying to get the infrastructure into a working order. I worry that it's such a long road from here to where a "normal admin" like myself can sell Devuan as a stable system to management that there's a risk that Wheezy will go out of support first. I hope that doesn't happen, but if it does then it makes life difficult for the majority of us who rely on packaged stuff, but may need to meet manglement rules on using "supported" software (especially manglement that's used to working with Windows which is where the bulk of work's business lies.) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Detailed technical treatise of systemd
Jonathan Wilkes wrote: > I cannot for the life of me understand the quote from djb starting, "Don't > parse." > > What is it he doesn't like, and how does his text0 format keep him from doing > what he doesn't like? How I read it was ... Don't have a program you want to be controlled by another program use "human read/writeable" interfaces - use a well defined API. The problem being that if you use the generic command line interface, you need a parser to accept a variable number of options, in a non-determinate order and combination, and that parser may well have bugs (either in the parser or it's view of what the allowable options are). In addition, the code you write to generate that arbitrary list of arguments may also have bugs. So rather than going from an internal well defined structure of what you want to pass, converting it to "human readable text", and parsing it back to an internal well defined structure - just pass the well defined internal structure between the programs using a binary API. There is probably still some conversion between internal structure and public API at each end, but that's a more tightly defined conversion. Well that's how I read it anyway. I don't think the text0 format was directly related to this. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Quick start guide to uprading to Devuan and configuring minimalism
KatolaZ wrote: > ... but please: do not urge people > to reboot, ever. There is simply no need at all to reboot, and in the > ovewhelming majority of use cases it is not necessary at all to use > the latest kernel available, unless ... With all due respect, I disagree with that. I don't generally "reboot to fix it" though that is sometimes the answer. But in the case of having upgraded the system (especially if it's a major dist-upgrade, and in this case a cross-grade), I would normally reboot for several reasons : 1) If the kernel has been upgraded, then (ATM) a reboot is needed to be using it 2) The upgrade process has quite likely done a grub-update - and I'd like to know now, not some random (could be weeks or months) time in the future, whether that grub update is OK. It most likely is, but I think any experienced admin has experienced a non-booting system at some point. 3) There's always the possibility that some process wasn't properly stopped-started during the upgrade - leaving a situation where there's a process running with the old binary and old config which we think we've upgraded. No it shouldn't happen, but I'm fairly certain I've experienced it in the past. So yes, you are correct that we shouldn't need to reboot (and especially not upgrade-reboot-upgrade-reboot-... rinse and repeat until we run out of upgrades like with Windows), it's a valid thing to do after a major upgrade if we want to be completely 100% certain that were running the kernel we've installed, and running the software & configs we've installed, *AND* that the system will actually boot with the changes we've made. The only thing worse than having a problem with a system, is having a problem with a system which falsely appears to be a new problem because it's been sat there just waiting for an opportunity to show itself. You're then scratching your head trying to think about what's changed just now, while in reality we need to remember what we changed weeks or months ago. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Detailed technical treatise of systemd
Rainer Weikusat wrote: > ... but the conclusion is "Whoever believes parallelization beyond starpar > will improve 'booting speed' for this machine is sadly mistaken". I've done no measurements, but my "gut feeling" is that for the servers I manage (and my OS X laptop), the limiting factor is disk I/O. Thus parallelising service startup won't help much (if at all) because it just means all the services fire up and take longer each to start. Eg, (as a simplification) if you have 10 services that take 10s each to start, then they'll take 100s total - starting them in parallel probably means they'll all take 100s (give or take). All assuming no dependencies of course ! Of course, it's possible for some workloads to take longer in parallel. Having (taking the above example) 10 services all accessing the disk means losing the benefit of any file contents locality on the disk - so instead of reading a file in one go, the disk may head off elsewhere at some point (to service one of the other services that's starting) and have to come back to read the rest of the file. I de recall in a previous job we had some Apollo Domain systems - that dates it, they were 68020 based IIRC. Upstairs, the naval architects had a bigger machine for number crunching finite element analysis*. To start with, the system was "fairly open", but a few engineers abused it and they had to lock it down. In the end, jobs had to be submitted and one of the admins ran them - separately. Before the lockdown, people would just fire up their own jobs which could mean things like swapping out and the jobs took longer than if run sequentially. In the worst case, one or two people actually went as far as killing other peoples jobs to get theirs running ! Where parallel startup will help is if you have a lot of cpu intensive tasks - and then (and only then) will those interleave execution with those waiting on disk I/O. Can't say I've noticed many of my services being particularly CPU bound during startup. And back to an earlier comment about the difference between "booted" as in shows a login or the desktop and "booted" as in "can actually be used ... On my Mac, I get the desktop fairly quickly but the machine isn't usable. I have a fair bit of software set to auto start as I always use it (eg mail programs and such), or the system will auto start the programs that were running before the last reboot. Even after programs have stopped launching (so it's possible to do anything without the foreground application changing), the machine isn't usable as it's just so sluggish - anything needing disk I/O (which is just about anything immediately after a reboot) just has to fight it out in the I/O queue. I have to sit there, with the disk rattling quietly away to itself, for what seems like a couple of minutes between the desktop appearing and the machine actually being usable. As for my servers, I don't reboot them very often and normal start times aren't an issue - far more of an issue is fsck times if it's been a long time since the last reboot or an uncontrolled shutdown. Having daemons start predictably and reliably is far more important than shaving an odd second off here or there. Besides, (on bare metal) there's all that BIOS stuff that happens before the OS even gets a look-in - I sometimes wonder if Dell and HP have a competition on how long they can make this process ! * I vaguely recall that at the time being told that it was a toss up between Apollo and Sun - but Apollo had the higher spec number cruncher at the time and that's what swung it. I wasn't involved all that much, I was just a user back then. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Detailed technical treatise of systemd
Didier Kryn wrote: > Why the hell did they invent suspend-to-disk? I take it you don't like the idea ? My only laptop is OS X, and I tend to leave so much open (text files of temporary notes, a gazzillion web pages/tabs, mail (home), mail (work), and a few others. To boot takes several minutes*, sleep takes a second or two. But for a while I was using a laptop without a working battery, and then suspend to disk was a godsend. Takes a little longer writing 8G to disk and reading it in again when waking, but really really made sense for me - and as implemented in OS X works very well. While I now have a working (more or less) battery, it will still suspend to disk if the battery is almost down when I sleep it. As an aside, a lot of years ago with a different hat one, we had a customer who moved around a lot - but didn't actually need "portable" use. Laptops weren't common back then, and Apple's "portable" cost £4.5k, had a crap display, and was generally descibed by others as "luggable" (I've seen smaller batteries on a motorbike !) In the end, he settled on a Mac LC (original version, https://en.wikipedia.org/wiki/Macintosh_LC) with an extra keyboard, mouse, and monitor. The computer itself was small enough (just) to go in a briefcase. Suspend to disk would have been just brilliant for that application. So personally, I think it's a wonderful idea. If there are problems in some implementations, I'd say you should direct your displeasure to the implementation rather than the concept. * As discussed before, the "system" boot time is fairly irrelevant - the system isn't usable for my workload for a couple of minutes after the services have loaded. 10 or 20 seconds either way would be irrelevant. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Detailed technical treatise of systemd
Didier Kryn wrote: >>> Why the hell did they invent suspend-to-disk? >> I take it you don't like the idea ? > No. I don't dislike the idea. I admit it is brillant. I'm confused then - but that's not hard ! > This leads to the conclusion: boot time doesn't matter if you never shut > down, but it matters if you do it often. Yes and yes > We might have reached this conclusion earlier :-) Yes ! > but there also has been a discussion on the reality of the gain in boot time. Yes, and the consensus seemed to be that for many workloads, on or both of the following are true : 1) The "services start time" is only part of the overall boot time, and shortening it by "a bit" won't make a huge difference. 2) Parallel starting services often won't make a huge difference to startup time, and in some (probably rare) cases may actually make it longer. > Maybe you never shutdown, but some, like me, prefer to put their laptop back > in a well-know state from time to time. Indeed, I do reboot from time to time. Sometimes it's because I didn't keep an eye on battery state - it's getting towards the end of it's life and I can no longer rely on the "low battery warning, followed a while later by a forced sleep and suspend to disk" that happens with a healthy battery. More often it's to clear memory - something seems to have a leak, and I'm not that convinced OS X memory management is all that good. But normally, I just use sleep mode. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ntp (Was: Detailed technical treatise of systemd)
Didier Kryn wrote: > NTP does not adjust the RTC brutally; it seems to adjust slowly the frequency > so that synchronization happens without the process being noticeable to other > apps - it can take hours. On shutdown it saves the RTC settings in > /var/lib/ntp/ntp.drift, and (AFAIU) /var/lib/hwclock/adjtime. After some days > of running NTP, your RTC is well trimmed and does not drift much. It does not > stop running when you power-off your computer. Therefore, at startup the > discrepancy is very small - unless the battery of the RTC is dead or you > stopped the computer for a year. Yes, that is correct operation. It can take a while to settle down initially, especially if there is a large offset to start with, but it generally settles down and should have the clocks synced within a fraction of a millisecond. If the offset is very large then it will step the clock. I have a number of embedded systems that didn't have a clock battery - and hence had no time at startup. ntpd still copes with setting the time, the timestamp in the logs jump from 00:0n:nn 01-01-1970 to the current time once ntpd gets started. Didier Kryn wrote: > I use the package simply named "ntp" in Debian repo. That is the ntp.org client. > This ntp client doesn't give up. Correct. However, I have used systems in the past which ran ntpdate at startup. From memory, this may pause the system for a while as it gets multiple times from servers and sets the clock. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Quick start guide to uprading to Devuan and configuring minimalism
Mitt Green wrote: > But I also have libsystemd0 file in /etc/apt/preferences.d containing: > > > > Package: libsystemd0 > Pin: origin "" > Pin-Priority: -1 > > Does anyone have any tips for getting more meaningful output from apt when something fails ? Specifically, not long ago I pinned systemd out like that and tried a dist-upgrade to Debian Jessie to see what would happen. It took some time (and trial and error) to figure out which package was blocking it since apt seems to baulk at something that depends on something that depends on something else that is blocked - making it hard to figure out what that something else actually is. In my case, turned out to be clamd causing the problem. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Interesting read from RMS
Jaromil wrote: > Of the three perhaps only Linus did, after > all he is an active programmer and reads > regularly code. But he is refraining from > doing universal statements pro or against > the whole of systemd, while interacting > on details, which I think is wise to do for > a leader. I suspect it's a bit more subtle than that. I get the impression that Linus is "very passionate" about Linux (the kernel), but agnostic about what it's used to run - so at the moment, systemd really doesn't impact 'his' project. Now, if they start trying to force stuff into the kernel, I quietly predict some choice language in response. Also, for other areas where there's shenanigans going on : http://nerdvittles.com/?p=11602 Ward Mundy has written fairly extensively on how Sangoma have systematically borged FreePBX into something that "doesn't work properly" if you don't pay them for it - using similar tactics to Tivo. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OT: Degree?
Mitt Green wrote: > I mean, that's something normal, neither years in the field > nor degree won't make you smart and experienced > (years are not equal to experience) alone, something > has to be inside your skull. That echoes something I wrote off-list to the OP. Having a degree is good because a lot of large employers require it, and many other employers/HR agencies use it as a filter. Doesn't have to be a computer related one - mine is in Engineering and it's amazing how many engineering students don't go into engineering after graduation by choice, it's taken by many employers as a good grounding for many other jobs. I do feel that a "good" basic education in "computer science" (whatever it's called) is good. Having a good understanding of the fundamentals means you can pick up and learn whatever language du jour/passing fad is. If you only ever learned about data storage, sorting, and so on from the perspective of a single high level language, then that may make it difficult to grasp other languages (depending on their nature of course) - the old "if all you have is a hammer, then every problem is a nail" issue. That doesn't mean you have to be proficient with pliers and screwdrivers - but if you at least know how to recognise when a hammer isn't the right tool then you are half way to a decent job. But after that, nothing beats experience. I was lucky in that apart from when I was leaving school, I've never had to compete to get any of my jobs. I started as a junior design engineer in a local (large, very large) engineering firm, left to set up in business with some friends as the local Apple dealer), found out the hard way that we had "more enthusiasm than business acumen", started a smaller general computer business with one of them, then one day I walked into the MDs office of one of our large customers and asked if there was any chance of a full time job. I was there for 10 years - primarily IT (in a department of 3 1/2 people), but dealing with just about anything that used electricity. When that business got driven down the plughole by the beancounters who took over, I was one of the many that "left" - at the time it was very painful, but in hindsight it was good for me. I went to see the same person (who had been forced out years earlier and how had fingers in many local businesses) and before I'd even asked, he'd outlined 3 possibilities. He more or less put me where I am now (general IT/Internet/small hosting company), and I've been here 10 years. So those two jobs came about because I asked for them, and the person i asked knew that I could turn my hand to many things. Sadly he died in an airplane accident some years ago. But you have to get that experience first. that may mean taking any job you can get at first. Any junior admin, helldesk, developer, whatever job will get you onto the bottom rung. Take the opportunity to look around and see what different people do - your first choice of career may not actually be what you want. There is no such thing as "IT" - it's a very wide field with many different roles. Watch people closely. Tend to stay away from the brash loudmouths, watch the quieter ones who just get one with stuff (and are probably moaning about fixing the sh*t left by the loudmouths) as they are probably the more professional ones. Take time to talk to people about what they do, why, what's good and what isn't. And when you make a cockup - as you will, more than once - don't just shrug it off, look at what went wrong, why, and how you can avoid it again. If you have decent colleagues, then they'll be supportive if you're open about asking for advice and it will improve your reputation with them. Sadly, you will also find environments where openly admitted ot having made a mistake will be used against you - if you find yourself in one of these, then the best advice I can give is to get out as soon as you can as these are toxic and don't promote learning or good practice. In that vein, if you are a witness to someone else making a cockup - don't hold it against them (unless they really were stupid and don't want to learn from it) - but use the same process - what went wrong and what can you learn from it. Lastly - get your daily Dilbert ! http://dilbert.com ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] alternative to raspbian without systemd
Gregory Nowak wrote: > From what I read, the 2nd generation B has one 10/100 ethernet port > which is a network card on one of the pi's usb ports. Besides that, it > does have four usb ports, and you can hook up hubs to those as well of > course. That is correct - one 10/100 ethernet which is a usb-ethernet adapter which from memory is part of one usb hub chip. That's the other thing to bear in mind - it only has one USB port on the system chip, and that's split out by a hub to provide the 4 external ports (and the ethernet) the user sees. So for I/O intensive applications it's not the best option. Also consider the other issue, it's using an SD card for storage. This isn't ideal in an environment generating lots of disk I/O (such as logging from BIND and all the other system logs). AFAIK SD cards don't have wear levelling etc. I'm in a similar position to the OP - until I get the house to the point where I can get all the "IT stuff" set up properly, I won't have a server I can tack a router VM into. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] top posting, was: Re: Debianising my uploaded version of netman.
shraptor wrote: > I must admit I am really clueless to what is considered good practice in > mailing-lists. ... > I am not rude on purpose but I truly don't know mailing-list style of > interaction. > Should I delete this or keep this? Write here or write there? In "days of old" it was accepted netiquette that when replying to an email, you would quote enough of the original text to give the context for what you are writing, and then add your reply after the question/statement. The very act of trimming the quoted material is, IMO, useful in itself in that it makes the writer think about what is and isn't important to set the context - sometimes that may just a one liner, sometimes it may need selected bits from several pervious quotes. Then along came Microsoft and inflicted Outlook on the world. This defaulted to quoting the entire message and leaving the cursor at the top of the window ready to type. This was at a time when the internet as a mass communication tool was taking off, and so there was a mass of new users coming on-line who had a tool that defaulted to "doing it badly" (like a lot of stuff from Microsoft). At least Outlook doesn't actively stop you doing it right - unlike certain other systems (Gmail has been mentioned). "The tool I use doesn't allow ..." is (IMO) a rather poor excuse when there is no compulsion whatsoever to use a specific tool. Even Gmail supports using an IMAP client so if their web client doesn't work properly, you can still use Gmail while doing things right. Complaining loudly and often to Google that their stuff is broken would also be a good idea - but I fear the few of us who care enough to say anything are just noise in the background and will be ignored no matter what we say. Of course, because all the excess quoted material is off the bottom of the screen, it's out of sight and out of mind - so doesn't get trimmed. Hence when you see emails that, after a few rounds, can get to be hundreds of lines long (complete with dozens of quoted signatures) for a one line reply. IMO the reason for not top posting is summed up thus (I didn't write it) : A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? In real life, if someone asks a question, it's natural for an answer to come after it. A non linear timeline isn't something we are used to - that's only for science fiction. The thing is, bottom posting - though really bottom posting is just a specific case of inline posting - suits pretty well any situation. Top posting often doesn't, which is why you'll often see messages in "the top posting world" where someone wants to reply point by point and starts with a top posted line something like "comments in red" (they have to use colour, because the same bit of crapware that brought us top posting is also crap at quoting properly) and then proceed to post inline. > It's like it's only for those initiated in the secret art? It shouldn't feel like that. It's not secret, though good writing is an art. I agree with Rainer Rainer Weikusat wrote: > 'Top posting' vs 'bottom posting' is a false dichotomy (could also be > regarded as strawman) For a lot of users it's simply that no-one ever taught them proper netiquette and they just assume that the default in what ever tool they use must be correct and/or they just follow what everyone else seems to do. But for many I do suspect there's an element of laziness. I accept that for some they are busy doing important stuff, but for many I do simply think it's a "can't be bothered, I'll bash it out and get on with what's important to ME". My view is that, especially if asking for help, one should put some effort into making your messages easy to read. That ony takes one person's time - if it's hard to read then it may take time from tens, hundred, or even thousands of people to follow it. If you want someone to help you, then it's good practice to make it easy for them to do so. If you write in a manner that suggests that you do not value that other person's time, then why should they give some of it up to help you ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which email client can I use to properly quote emails?
Steve Litt wrote: > You might wonder why I'm so partial to IMAP: A fair question indeed. I think a fairer question would be why anyone would be against it ! OK, there's one reason - and that's if you are not running you own mail server in which case you are reliant on your provider not losing your mail for you (http://www.theregister.co.uk/2006/08/03/plusnet_loses_deleted_emails/) Other than that, why would anyone not be in favour of a system where you can have one single mail store, in an open format (if you have your own server) so you can't be locked into one server software, accessed by open protocols so you can use any client (as long as it supports IMAP), and you can use any mix of clients you want and have one unified view of your email ? I've been down the route of importing emails from $old_client into $new_client before - and it wasn't pretty in the end. Personally I'd love to find a properly working replacement for Eudora - I just hate this "everything in one window" approach everything seems to use these days. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Which email client can I use to properly quote emails?
Florian Zieboll wrote: > If the fear of loosing your mail archive is the only reason to avoid > IMAP: Many IMAP capable mail clients support synchronizing to local > folders. For those that don't, you can easily create a local (or remote) > backup with isync/mbsync which could even be evoked by the mail client > itself, like ol' fetchmail: just set up an additional "backup account". Just make sure that you either keep backups of the local copy, or make sure the sync process won't delete stuff from the local copy. Otherwise, if the provider (or you, or you mail client) "gets it wrong" and your mail disappears from the server, then it'll also disappear from your locally synced copy as well. There was a case not that long ago where a journalist has his Apple account hacked. The hacker first used social engineering against another outfit to get more details, then used social engineering against Apple to get access to the account - and then deleted all the photos held online. But because photo syncing was on, the journalist found all his photos disappearing from his devices as well as the cloud. Syncing is a powerful tool ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Backups (Was: Which email client can I use to properly quote emails?)
Adam Borowski wrote: > In other words, you always need proper (ie, versioned) backups. > Using a "cloud" is no excuse, as those guys are not paid to be competent > (from your point of view), they're paid to generate revenue. I didn't say cloud providers weren't paid to be competent - the disappearing photos issue was a basic "attacker has enough info to operate password reset mechanism" problem, and he got some of that info from social engineering another account at another provider. That latter bit could, in many cases, be as simple as looking at the target's Farcebork page to find their birthday or pets name. But yes, it really comes down to "have good backups". Plus, "cloud is not a backup". Sadly, it is "not that uncommon" to see supposedly professional IT people pushing cloud as though it's a "stuff it in the cloud and it's an SEP*" fix for all security and availability issues. Seriously, I have seen cases where "backup" is implemented as "syncs with a cloud account, no further thought required" * SEP = Someone Else's Problem Simon Hobson ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Debianising my uploaded version of netman.
Edward Bartolo wrote: >> No matter what you believe about this, overriding a command with itself >> is a pointless exercise. dh_auto_clean will be invoked as part of the >> 'dh clean' sequence, cf > > Please, refrain from using offensive and vulgar expressions. 'cf' is > "complete fuck" which implies that my work is a total loss, and that > is humiliating, demotivating and insolent. This must be one of those "different cultures" things that can crop up with dispersed discussions. I'd never have though of your interpretation, to me it would mean "compare" (https://en.wikipedia.org/wiki/Cf.) Though when looking that reference up, I see that to some people it could refer to Cystic Fibrosis - but get down to page 2 (am I the only one that goes past page 1 of Google's results ?) and it could also mean "Climate & Forecast". Neither would be applicable here. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] the consistency of omelette
Florian Zieboll wrote: > You know, I am certainly not the person who wouldn't agree to the > concept of breaking eggs to make an omelette. But it's completely > unnacceptable to go to the supermarket and break everybody else's eggs > too, just because you want to make yourself one little omelette... Having read it in context, it really makes sense. In fact he sounds quite rational. Hard to rationalise between this and what's been inflicted upon the world by him - or perhaps he just doesn't see SystemD as breaking anything (at least nothing that doesn't need fixing). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Not getting your emails
Mitt Green wrote: > Go Linux wrote: > >> Just a heads up. None of your emails are coming through. Not even in spam. >> I >only know that you've posted when I see quotes in the responses. I have >> a >yahoo address for this list and it has been a problem for me too. > > The same thing about you: once you wrote to "Our friendly communinty" I didn't > get your email. You are not in my spam folder either. Mine is yahoo too > as you see. Ah, that'll be the "we know it breaks stuff but we're gonna do it anyway and anything it breaks we can simply declare 'wrong' even though it's completely legitimate" SPF/DMARC/whatever they've implemented. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Life's too short to reply to trolls
Dragan FOSS wrote: > If the group is so weak, that one opponent may threaten it, then something is > wrong with that group, right? No. As pointed out, the "discussion" has distracted people from the task in hand. No-one here has to justify their desire to be systemd free to anyone - yet that's effectively what people have been asked to do. There's been a "long discussion", of a form that could be off-putting to someone new to the list - probably because they have just found out about this "Debian without the malware" distro. Steve Litt wrote: > ... get down to the not inconsiderable business of bringing the Devuan > sans-systemd OS to beta and then to production status. +1 I've hesitated to post a couple of times when it would have been appropriate (didn't want to add noise), but since I am posting, in my opinion there's only a small window left. Debian Wheezy is already to the point where some packages are out of support, last time I updated on of my systems I got the message : > php5 (5.4.45-0+deb7u2) wheezy-security; urgency=medium > > * PHP 5.4 has reached end-of-life on 14 Sep 2015 and as a result there >will be no more new upstream releases. The security support of PHP >5.4 in Debian will be best effort only and you are strongly advised >to upgrade to latest stable Debian release that includes PHP 5.6 that >will reach end of security support on 28 Aug 2017. It won't be long before Wheezy is out of support and many people will be at "decision point" with a PHB demanding to know why an unsupported OS is in use. Once systems are updated to Debian Jessie with SystemD and the world hasn't ended, it could be hard for many to switch afterwards. From my POV it does appear that there is still quite a bit to do in terms of getting the "transparent infrastructure" that most people will be expecting of a mainstream distro. I'm afraid I don't have the skills to help or I would be doing. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan's goal: was Our friendly community
John Hughes wrote: > Yes, the impression I get around here is that this is a religious argument > for most of you. > > I had hopes for Devuan, but the lack of rational thinking convinces me that > it's going nowhere. There's no lack of rational thinking. People here don't want to run SystemD, and what's more, we don't want to encourage people to add gratuitous dependencies because "it's OK, there'll always be a bit of SystemD present". While libsystemd0 may appear harmless, it isn't for two reasons : 1) By making it "OK" to have because "it does nothing", it encourages people to assume it's presences and use it - rather than actually checking first or just not using it if not needed. 2) I don't have the skills to check, and keep checking, that libsystemd is in fact "harmless". Just because it doesn't do anything now, doesn't mean that tomorrow someone will find that "doing nothing" is inconvenient* and so some "does more than nothing" code gets added. * I'm thinking, someone decides they want to use a systemd function, but finds that the call "fails" when systemd isn't installed. So instead of just accepting that "if systemd isn't installed, they'll have to do X another way", they may well suggest that the functions supporting X are moved from the systemd package to libsystemd0 - "it's still OK, it's only a tiny support function". And so it goes on, like boiling a frog, until having libsystemd installed equates to running significant chunks of systemd itself. Now, you may consider "doesn't want any part of systemd on my system" as religious zeal. It's not, I just don't want stuff that as far as I can tell is primarily designed to reduce reliability (in terms of the stuff I run). Not a single (claimed) "benefit" of SystemD is actually a benefit for my systems, in fact far from it. While I'm not a "programmer", I do know enough about the subject to read between the lines of some of it and see just how bad it is. And yes, I've seen a function implemented while has just one function to cause data loss - why else would anyone go to the trouble of making an "async" sync call and complain about sync being sync ? It may or may not have been fixed, but the very fact of it getting into the project in the first place simply shows that the project is run/managed by people who (being generous) simply don't have a clue. I don't want that on my systems. I *like* text log files. I *like* shell script init files. I *like* sequential (deterministic) service startup. These things have got me out of the brown stuff more than once ! I'm not in the least bothered about shaving a few seconds off the *apparent* boot time given that the hardware alone can take minutes before the OS itself gets to start. Like most, iff SystemD was "just an init system" as some of it's supporters keep suggesting then no problem. I'd just not install it and carry on. But it isn't an init system - it's a Windows style "blob" of all encompassing stuff that goes against everything I like in Unix/Unix like systems ! > Bye. Good bye - please don't come back until you've understood. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question on Devuan
Linux O'Beardly wrote: > While many here would probably say it's not a good idea to run servers on > Devuan until a production release, I am already running it on a number of > servers. That's good to know - I need to find time to do some testing myself. > R. W. Rodolico wrote: > BTW, while I can not contribute the skills necessary at this point, my > offer of a mirror still stands, whenever that becomes needed. Resources > I have, but my programming skills are so far out of date I'd be a > liability. But, resources I would be happy to share when/if you need them. I too would be able to offer disk space and bandwidth - but that would be just the ~15Mbps of my home connection rather than any "fast" hosted server connection. I suppose the biggest question has to be : I assume people are working towards a situation where the user can "s/debian/devuan" in /etc/apt/sources and then dist-upgrade - I can't help feeling that for many (perhaps the majority) of users, adding some random repository might feel a bit "dangerous". Does anyone have a feel for how far off that might be ? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nmap in Debian Wheezy
On 23/12/15 02:19, Emiliano Marini wrote: Wow thanks man! # apt-get install --no-install-recommends nmap That can be set in apt's config files, in /etc/apt. It really helps maintaining a system .. you can look at the recommends listed and install the ones you want. I've kept my old sidux/aptosid setup ... this from /etc/apt/apt.conf.d/ // apt defaults for aptosid // apt 0.7 introduces automatic behaviour unsuitable for sid, revert this // auto-remove breaks on meta packages APT::Get::AutomaticRemove "0"; APT::Get::HideAutoRemove "1"; // Recommends are as of now still abused in many packages APT::Install-Recommends "0"; APT::Install-Suggests "0"; Debug::pkgAutoRemove "0"; // PDiffs reduce the required download for apt-get update, but increase the // CPU requirements and quite often fail. // Acquire::PDiffs "0"; documentation seems lacking, but example files are a great fallback as long as programs use plain-text ones. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nmap in Debian Wheezy
On 24/12/15 02:12, Emiliano Marini wrote: Thank you Florian, I didn't know that tool: apt-rdepends - Recursively lists package dependencies I will try it. apt-cache does lots of information stuff including depends, rdepends (which is reverse depends), show (which gives description, suggests, recommends, version ...), showpkg (which is a summary), search, check outman apt-cache Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] nmap in Debian Wheezy
On 24/12/15 10:36, Emiliano Marini wrote: Yeah, I checked that manpage, but apt-cache shows no info about recommended and suggested packages, only dependencies (at least in wheezy) apt-cache show package gives info, including recommended. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Preferred automounter behavior?
Steve Litt wrote: > With /dev/sd? you can at least try to guess which one got > plugged in last, and then verify. It's certainly no warse (probably better actually) than the Windows world where it could be E:, F:, or something else - and it could even change depending which USB port it was plugged into ! On that latter one, from listening to some of the helldesk chatter, it seems over the years we've had problems with customer backups failing because the customer plugged the removable drive into a different USB socket, so it got a different letter, and so the backup failed. Talk about a pile of steaming manure built on top of another pile of well seasoned manure. Drive letters, so 1970s :-/ As a Mac (OS X) desktop user, I'm used to drives being mounted on /Volume/ where is the filesystem name (aka label). I'm trying to think if I've had a situation where there's been a clash - but I suspect if there is then the second one mounted would be mounted on /Volumes/-2 which seems to be the pattern OS X uses for various things when there's a clash. As a Linux (almost all command line) user, I'm used to sdxn for working with partitions. Since this program is aimed at people not using file managers, then I rather think most of your target audience will be similar. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I've got the automounter running
Didier Kryn wrote: > There remains a fundamental problem with automatic mount/umount. While > automounting is safe, auto-unmounting is not if it is triggered by device > removal. > Unmounting must be done *before* removing the device if anything has been > written to it, otherwise data is lost and the filesystem may be corrupted; > also running applications with open files in the mountpoint can broken. Indeed > auto-unmounting is not if it is triggered by device removal. But there is a slight issue in that if the user has yanked the drive, there isn't much you can do about it. Short of having precognition so you know in advance, or modifying all hardware to support locking the drive in, once the drive is disconnected then you have no options - other than to tell the user off. Blame Micro$oft :-) Long after Apple required a user explicitly eject a floppy disk (which got them a lot of flak IIRC), Micro$oft still worked on the "pop the disk out when you feel like it" process. OS X will tell you off if you yank a drive without ejecting (unmounting) it - when you put it back, you'll be told off about it not having been ejected properly. Windows still doesn't do that AFAIK - it just silently "fixes" it without giving any clue to the user that they did anything wrong. A couple of years ago, I surprised a group I'd given a presentation to by "Safely removing" hardware before I yanked my USB stick ! ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I've got the automounter running
Steve Litt wrote: > I did a test. I created hello.txt, put "hello world" in it, saved it, > and yanked out the thumb three seconds later. Of course the > whole /media/sdd1 tree vanished. When I plugged in the thumb again, > hello.txt contained exactly what I'd typed in it. Now of course, this > is an anecdote, not a mathematical proof or a statistical study, but it > does point to the possibility that sometimes all your stuff gets > written to the thumb and everything's OK when you yank. Timing is everything. When you write data to disk, it initially goes into the write cache as a dirty page. Unless the user (or their program) explicitly syncs that out, then there it sits until ... The cache gets written out when the background system processes clean up and write the dirty pages out to disk. How long this takes depends on tuneable kernel parameters and how busy the system is. If the system, and in particular the storage, is otherwise idle then IIRC your small file will get written almost instantly. If the system is really busy, with a large dirty cache, then it'll take a lot longer. As another test, try running "cat /dev/zero > /media/sdxn/testfile" then save your new file and immediately pull the drive. This page seems to be a decent writup : http://www.westnet.com/~gsmith/content/linux-pdflush.htm It's not something I've every fiddled with on Linux, but I do recall hearing an "interesting" tale of a SCO Openserver admin who didn't know what a process was and got rid of it. This was the cache flushing daemon - and he found out the hard way, when the system crashed, what it did ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I've got the automounter running
Didier Kryn wrote: >That's the logic one would naively expect but I'm not sure of it. I'm > afraid the data remains in the cache and not backed-up to disk until some > process needs room in the cache. You can do the experiment of writing data to > a usb memory stick and then wait long after the light has stopped blinking. > Then you can either sync or umount the device and it will blink again for > some time before the command returns. Umount will cause some disk-i/o. But it is normal for dirty pages to be written at some point - and not just when the space is needed in cache. You can see this by watching the dirty pages value in /proc/meminfo. You can make some dirty pages, and after a while you'll see the value go down again. Not having this cleanup would be a recipe for two things : 1) crap performance that might not be that much better than with no cache. In effect, instead of having to wait for your new data to be written, you'd have to wait for something else to be written to make room for it. As it is, it's not too hard to see this effect with certain workloads. 2) Almost guaranteed filesystem destruction - or at least massive data loss/corruption on system crash when the dirty pages don't get written. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] I've got the automounter running
Didier Kryn wrote: >Down to zero? Depends on what the system is doing ! I've just checked several of my systems, one showed 12k when I logged in and dropped to 0. OK, that's a router so doesn't do much disk I/O - just a bit of logging. Another (my mail server amongst other things) showed 312k when I logged in, and while I've been watching it has been down to 16k and up to 920k. Oh, just before I hit send, I've just seen this one down to 0 as well. Even my MythTV server (which is currently recording and commflagging two programs) is varying between 1/2M and 9M dirty - oh, just dropped to 136k dirty. OK, this is a slightly special case because MythTV fsyncs the recording streams about once/second - but the commflagging and database updates that are done constantly aren't. So yes, observation confirms theory that if there is a period of no writes then the dirty pages will get written to disk. >Who "have to wait" ? Apps don't have to: they get the data from cache and > write to cache. Maybe the disk-write policy depends on the IO scheduler as > the read policy does, but this layer is completely isolated from the > applications. Actually, apps will wait if the underlying system just "doesn't return" from a read or write call for a while - a system I used to administer had one particular process (an inefficient reporting tool) we could run which resulted in 99% to 100% wait i/o system status (and simultaneously causing our phones to ring with user complaints as their processes effectively stopped dead). If you rely on new writes to "push out" old dirty data then there will come a time when the underlying system will make the application wait while it makes some cache space available - in effect, write performance will become near enough identical to having no cache at all. One of the points of combining a write cache with a process that flushes it out is to give some "ready and waiting" space for intermittent writes. That way, many loads will never have to wait for disk as writes will go straight into cache. >Data was lost and filesystems *were* corrupted, at every such crash until > the advent of journalled filesystems. I started to install Reiserfs many > years ago to face this problem with crash. Indeed, but the more dirty data, the higher the risk and effect. There's a difference between a few k/M and hundreds of M of lost data. You also have to consider the effect of optimisation techniques (either in the OS, disk driver, or drive itself) re-ordering writes to maximise performance. Back to the original subject, once upon a time it was simply a case of "wait till the light goes out and then eject the floppy" because the systems didn't have a write cache - I'm thinking of "desktop" systems like Mac OS, DOS, early Windows etc. Similarly, often the effects of a crash were minimal because updates were written straight to disk - I still know people who think nothing of pulling the plug to shut down a system simply because "we've always done it that way". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposals for an xfce-desktop-lite
On 31/12/15 10:32, Steve Litt wrote: On Wed, 30 Dec 2015 19:46:03 -0300 Renaud (Ron) OLGIATI wrote: On Wed, 30 Dec 2015 22:25:53 +0100 aitor_czr wrote: I ought to like LXDE but that pcman file manager is rubbish! IMHO, YMMV etc. Do you really think so? I'm a hooligan of PCManFM :) Like you, Altor, I prefer PCManfm, and moreover think Thunar to be a piece of excrement... Cheers, Ron. Ron, Except for Thunar's hit and miss handling of media like thumb drives and CDs, do you have anything against it? Personally I like Rox as a light file manager, it has its own unique workflow which takes a little getting used to but after that it offers a GUI interface that is very usable via keyboard alongside text interfaces as well as via mouse and via touch. It has very few dependencies and also suits a tiling, mostly text interface workflow. I especially like its approach to opening items, it is easy to customise and have several options easily available. But it isn't a clone of nautilus etc, so will be unfamiliar at first sight. https://packages.debian.org/sid/x11/rox-filer Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposals for an xfce-desktop-lite
On 29/12/15 04:37, Steve Litt wrote: On Mon, 28 Dec 2015 11:16:17 +0100 Your subject intrigues me. There are 2 reasons I prefer LXDE to Xfce: 1) LXDE is much lighter 2) LXDE is more reliable If you can really lighten up Xfce, that addresses #1, and probably to some extent alleviates #2. I believe lighter usually corresponds to less bugs, or else I'd be using Redhat. Or Windows. note that the raspberry pi lot worked very carefully to put together raspbian as extremely light and minimal for a very small cpu but intended to be used by linux noobies as well as others. They chose lxde, it runs with very little extra baggage and is a very familiar style of interface, the default setup is to use startx from the console only when X is required, or add it to rc.local if a desktop and monitor are wanted. No idea what they have done now they use a bigger chip and have moved on from their old default install. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ummmm, no
Mitt Green wrote: > I reckon as long as his Fedora boots, he doesn't care. I think that's the key reason. Linus is concerned with the kernel - and while I suspect he has personal preferences about what is run on top of that, he's "detached" enough to take the attitude that what people want to run is up to them. Now, if people start demanding "broken" features go into the kernel to support their projects - then he's interested. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Windowmaker: was Proposals for an xfce-desktop-lite
On 01/01/16 02:51, Steve Litt wrote: On Thu, 31 Dec 2015 10:03:40 + This is why I suggested that the other person (I can't find his name right now) consult me before writing docs or a presentation. Every single problem anyone could have about Windowmaker, I've had. If he can explain it to *me*, that explanation will work for *everybody*, and the great nature of Windowmaker will shine through. We all know it's good looking, we all know that it's very lightweight: What's needed is a good document to really explain the Windowmaker philosophy, how to do things in Windowmaker, how to configure it so you don't need to create a million menus to drill down, and how you set a hotkey to perform an arbitrary command (like dmenu_run). I have been using dmenu for some time now ... with a couple of other tools that allow for a few tweaks to DEs to make them more comfortable for me, or indeed to set up kiosk style environments without any DE required at all. Use xbindkeys to set a hotkey ... xbindkeys is a way to get keybindings for commands easily, works anywhere in X, I have been using it to avoid each individual DEs different ways of doing things, and easily get some consistency no matter which DE I'm using. triggerhappy (thd) does the job in embedded devices without X running, it gets the events directly from input devices. devilspie can be a great help in setting specific window placements and such in X, it performs actions on newly opened windows. alongside a few tools like xwit, xclip and a others, even xte for stubborn applications, you can tame X on even the smallest embedded device. And the main tools above have more sophisticated scheme or similar configuration options if you want to put a little work into getting a specific X environment right. I'm using i3 as my desktop currently, it is very light, has few dependencies and will do most of the above without help (in a tiling environment) Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ummmm, no
On 01/01/16 06:05, Simon Hobson wrote: Mitt Green wrote: I reckon as long as his Fedora boots, he doesn't care. I think that's the key reason. Linus is concerned with the kernel - and while I suspect he has personal preferences about what is run on top of that, he's "detached" enough to take the attitude that what people want to run is up to them. Now, if people start demanding "broken" features go into the kernel to support their projects - then he's interested. linux is distinct from whatever may be in userspace in a particular use-case. For most systemd is irrelevant ... huge numbers of smartphones and pads are android/linux, huge numbers of embedded devices use linux with or without X and with their own userspace probably GNU based and often with boot and reliability requirements very different to anything systemd offers, most supercomputers now use linux with there own userspace and systemd is utterly useless there. Many corporate desktops that use linux are probably redhat or fedora with systemd/linux and the common personal distributions have switched (but seriously desktops are a very small part of the linux world!) I guess the debian push will result in an increase in the proportion of servers and virtual machines running systemd/linux rather than GNU/linux, but devuan will help keep the options open. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Steve Litt wrote: > This idea came to me while I wrote an anti-merge rant a few minutes > ago... I was going to reply to that, I'll reply here instead ... First off, thanks for answering a question I hadn't asked but had always wondered about the answer to. I "sort of" knew what initramfs was, but had always assumed it was "fairly simple" - I vaguely recall having poked about once in the distant past. TBH I've never really given it much thought, except when I've been fixing something and forgotten to update the initramfs before rebooting :-/ But over the last few days I've been tinkering in a "foreign land" to me. I use MythTV, I had one frontend running nicely, and due to changed personal circumstances wanted a second. I had an identical box lying around, so I thought "no problem - partition, make filesystems, copy all files, fixup fstab to suit the changed partitioning, install grub" just like I've done quite a few times with Debian (pre-systemd) systems. Could I make this ***ing system boot ? Could I ! After that experience, my view of Ubuntu has gone from "fairly neutral" to "WTF!" How could anyone make a system so flippin hard to get to boot ! Usually I find I can at least manually edit the grub stanza to get the root fs mounted, and rebuild grub.cfg and initramfs from there - but I couldn't even get that working. Best I could manage was to set root= to an invalid partition so it dropped to buybox. In the end I gave up and used dd to clone the disk - so much for UUIDs being unique ! And that's without systemd. Just to add, further proof that one of the claimed "benefits" of systemd is in fact a huge problem just waiting to chew people's backsides off. Had a problem with no sound - because the second machine has a couple of tuners that the original didn't, and so the sound devices were different. Blacklisted a module, rebooted, got sound. Next time I booted, got no sound. Because the hardware probing and module loading isn't deterministic - on the next boot a different module had loaded earlier and subtly changed sh*t (needed to blacklist another module). So anyone that tells me that non-determinitic bootup is a "benefit" better have thick skin. So yes, you are quite right that complexity is the enemy of reliability. The question shouldn't be "what else can we put in", but "what can we leave out". ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
John Rigg wrote: > Wasn't the original reason for having an initrd that the boot loader, > probably LILO at the time, couldn't handle a kernel image above a > certain size? I suspect you are thinking of the problem that it couldn't access sectors past a certain point due to limitation in the BIOS - that was the reason for a separate /boot which meant you could guarantee to have any future kernel within the range accessible to LILO. The separate issue is having a modular kernel - which I'm in favour of BTW. If you use LVM, MD (raid), disk controllers needing a kernel module, or one of a few other things - then you can have a catch-22 situation where the kernel needs to load a module to access a filesystem, but can't until it's mounted that filesystem, which of course it can't do. Hence the idea of initramfs where everything the kernel needs to be able to access and mount the root fs (eg disk controller drivers, lvm, md) is included in a "packed up" filesystem that can be loaded into ram and then used as a temporary root until such time as the real root can be loaded. I can see why distros would include everything and the kitchen sink - otherwise you get the amusing situation I've seem at work where the Windows installer can't see the disks until someone does the "insert device driver disk" steps to give the kernel access to it. But as pointed out, for most users, something simpler would be adequate. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] support for merged /usr in Debian
Clarke Sideroad wrote: > I see little choice but to make the merged bin option available, after > all this is all about choice, but for gosh sakes it should not be the > default. The issue - as I see it - is much the same as with systemd. If the upstream stuff adopts it, then it becomes a lot more work to maintain something different. SO having an option of split /bin and /usr/bin is moot if all packages assume they are merged. I noted from one of the links posted a comment in the FAQ that "/usr must be mounted early on by initramfs" - which really contradicts common sense in that initrd/initramfs should really only have the minimum required to get / mounted so that the rest can happen from there. I have worked with Unix systems in the past with separate /usr filesystem (SCO OpenServer 5 - ahh, nostalgia). Back then we had to create a boot and root floppy (yes I know some youngsters have probably never seen one) and I can recall the problems I found making enough room on the root disk to include cpio (so I could read the backup tapes and restore /usr). But given that (eg) USB drives are generally not smaller than GBs in size these days, it's hard to make an argument on disk space. Didier Kryn wrote: > The simple fact of splitting executables between two different directories > *is* a complication; merging them back would be a *simplification* :-). I've > read, from a guy who followed the story, that it was originally split because > the first disk was too small. Wether it has become later a usefull > complication can be discussed of course :-) It's still useful for some systems to have a small /[s]bin with just the bare minimum of tools - including those to repair and mount a separate /usr. As I mentioned above, there seems to be a belief in the Freedeskop camp that /usr has to be mounted from initrd/initramfs - which perhaps explains a lot (it doesn't, only if you have a broken setup is that a natural dependency). Put another way, the argument seems to be "we've b**gered this up, fudged round it with initramfs, so that's a justification for completing the b**gering up process" - IMO anyway. So I am still in favour of a system where /[s]bin contains only those tools which might be needed to work with other filesystems. I rather suspect that the Freedesktop people have a narrow view of the world where the only systems they need to consider are desktops (or laptops) with lots of resources. Anything else is an SEP* they can ignore. If what they do makes life hard for (eg) embedded systems people then that's just tough. * Someone Else's Problem ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] support for merged /usr in Debian
I wrote: > I have worked with Unix systems in the past with separate /usr filesystem > (SCO OpenServer 5 - ahh, nostalgia). Back then we had to create a boot and > root floppy (yes I know some youngsters have probably never seen one) and I > can recall the problems I found making enough room on the root disk to > include cpio (so I could read the backup tapes and restore /usr). I see that's not that clear - it was two floppies. The first was the Boot floppy which held the kernel - statically linked with the modules (drivers) the system needed as was standard for the system. The second contained the root filesystem. Each was limited to 1.4MByte unless you had esoteric hardware - like the 2.8MByte floppy I think IBM did. If your kernel was more than 1.4M then you were out of luck. If you tried to put more than 1.4M on the root fs then you were out of luck - the default selection of files didn't leave enough room to add cpio. Without these two floppies, the system was to all intents unrepairable should it have a problem ! No such thing as a "live system" cd back then ! I suspect people looking at "desktop" environments have never been down the route of carefully designing systems for best performance (for the hardware that's within your budget) - small fast disks (raid 10) for active data, larger slower disks (raid 5) for "less active" data, carefully balancing the disks across multiple SCSI busses to maximise throughput, etc. Those were the days - raid controllers that didn't support array expansion, off-line disk rebuilds, 2 days to download a driver disk update (no ADSL back then). Oh yes, no dynamically sized disk caches in SCO OpenServer ! That was a hard configured setting, with a hard coded maximum size limit - and yes I found out the hard way that the stated size really was the maximum (go one block larger and it just didn't boot) - see boot and root floppies above :-( While it's not really an excuse, I can see how someone who's never had to consider resource constraints might ignore "good practice" regarding resource usage. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
Stephanie Daugherty wrote: >> But what's the point of having modules "at the end of [the kernel] image"? >> You can just compile-in them. > > Simple, It's to be able to turn a packaged, distribution supplied kernel into > one that will successfully boot on obscure hardware - to be able to inject > the modules needed for drive controllers, filesystems, and other boot-time > dependencies into the image. Which would be not only faster, but also less > error prone, and easier to do than a full kernel compile and all the obscure, > potentially breaking choices that go with it. I vaguely recall from my days with SCO OpenServer that it did something similar. It didn't compile the kernel, but it did relink it when you made changes - presumably just meging the stock kernel with your drivers and with config options (such as disk cache size) configured.. What you propose sounds like something similar. Roger Leigh wrote: > The *real* goal here is something rather simpler: having both / and /usr > mounted in the initramfs. The primary reason for this is that there are > genuine problems with stuff on / needed in early boot having library > dependencies located in /usr. Libraries were moved to / on a case-by-case > basis, but it's really just the tip of the iceberg. E.g. PAM modules needing > openssl, datafiles from /usr/share, etc. It becomes a nightmare to > coordinate and manage, particularly when you also have to consider > third-party stuff out of your control. Simply ensuring that /usr is > available in the initramfs solves all these problems. ... Thanks for that explanation > See https://wiki.debian.org/ReleaseGoals/MountUsrInInitramfs > Looks like they crippled the /usr mount for the non-systemd case for no good > reason though. Well it would be easy to put it down to malice, but rationally it's more likely incompetence. Given how many people seem to have gone into "systemd or on your own" mode, it's likely that they have probably not considered the combination (or just don't care if it's broken for non-systemd users). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] support for merged /usr in Debian
Steve Litt wrote: >> Therefore, if you want to mount a disk partition, you either >> need the necessary drivers and filesystem built-in the kernel or have >> them in the initrd/initramfs (under /lib/modules). Having the module >> on the disk won't help -- egg and chicken. >> >> Didier > > If you didn't merge /lib and /usr/lib, you could load them from /lib > once the root partition was mounted. This was my entire point. But if the root fs is on a disk attached to a controller that needs a kernel module to use ? Before you can mount / and get access to /lib, you need to load the kernel module that's in /lib - chicken and egg. I have some systems where that applies - eg an HP raid controller needing (IIRC) cciss driver module. An ability to "link" modules into an already compiled kernel (which is how SCO did it) would make a sensible alternative for probably the majority of users - giving the kernel the ability to mount / and from then on gain access to all the other tools needed to mount anything else. chaosesquet...@cock.li wrote: > Please keep to the traditional Linux way and keep /usr/ etc as is. > This shouldn't even be a debate. There is always room for debate - argument and dictatorship, no; debate, yes. It may be that for the vast majority of users, there is no longer any rational reason to keep /usr - it is a debate well worth having. > Fork everything if need be, piece by piece (copy on write). I said you'd > have to do it anyway. The progressives will to infect every piece of userland > (and maybe the kernel too) they can, so as pieces fall to them it must be > forked. I get the impression that dev resources in this project are "somewhat limited". Yes, in a ideal world the entire Debian toolchain and supporting infrastructure would have been cloned, with every infected item carefully fixed and migrated. Given the lack of resources, it's more important to determine priorities and fix what there is resources to fix. Trying to do everything when there isn't the resourcing to back it is a a recipe for failure. So I would suggest it's important to keep focussed on the primary goal and get that accomplished (stable release) so there's something to show as a "success". Then build from there. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 00:31, Irrwahn wrote: On Sun, 3 Jan 2016 17:52:48 + (UTC), Go Linux wrote: Why are you merging the debian, backports and dmo repos? Is there a way to separate them? I have rarely used backports and always downloaded what I need from dmo when I first install and then disable it. dmo can really break things if you're not careful. ... (Note: I, for one, am so far fine with having the bpo and dmo repos merged, since I have been using those for quite some time, but mileage varies vastly, as we all know.) ... One more note: I have no evidence, it's really nothing more than just a gut feeling, but I expect less breakage to occur WRT dmo packages in the foreseeable future, since Debian returned to distributing ffmpeg instead of the libav fork (They did, didn't they?), and I am under the impression that a lot of the breakage was due to mismatches between those two. I am not familiar with recent compatibility, I have not updated any audio workstations for some time, they remain as is. working and never updated. But there has been a sad and difficult history of incompatibilities and sudden breakages using dmo when dmo library updates break non-dmo audio apps which have been built against debian libraries. The dmo libraries did not match the versions in debian, and this includes both the time before libav and since. ffmeg did not have a regular release system, dmo built more frequently and against more recent snapshots than the ones in debian. If you only used audio from dmo it was generally ok, but they do not cover a lot of audio needs. Based on past experience mixing those repositories would definitely exclude using devuan from any audio workstation, or any system which needed other than standard desktop audio needs. It is probably mostly ok with desktop audio. It will certainly mean I cannot use devuan in most machines I look after. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan Weekly News LX
On 05/01/16 00:43, Didier Kryn wrote: Le 04/01/2016 12:29, chill...@use.startmail.com a écrit : Aside from the growing strength of the community, we have seen significant progress towards init freedom in Devuan and the approaching beta release. Important init freedom issues have been solved, and security issues will soon come into focus with an eye on the beta release for critical security updates. We are calling for volunteers on this, so feel free to discuss this on the mailing list. We are discovering day after day that "init freedom" is about the emerged part of the iceberg. Debian still pretends to offer init freedom. What is under the sea level is a whole monolithic operating system absorbing all critical Linux subsystems like a black hole. Therefore escaping this monster means much more than init freedom, it is something like keeping a free Linux/Gnu OS. It makes more sense every day that RedHat and Debian should rename their OS Systemd/Linux in place of Gnu/Linux. It should make sense to them as well, but I'm afraid they deny the reality. There was a very aggressive push to drop the GNU from the GNU/linux name some time ago, it was fairly successful. But of course android/linux is just as much linux as any other system with linux as the kernel (and because of that I can compile a suitable busybox, put it in the right context and get a really useful tablet). Though certainly it is no *nix. Many other routers, fridges, cars or desktop computers are linux. It is the GNU part that makes one or other of them a *nix, it is that part that is being steadily undone alongside the introduction of systemd. Much more so than OSX (the last time I looked anyway) where its toolchain underneath the GUI is still very unix. Apple and Google have the resources to make a decent effort at a big, unified, locked-down, we-know-what-you-need-just-shut-up-and-consume, GUI dominated system. If I wanted a unix like that I'd use OSX and drop in some of the tools that Apple leave out by default, they do fashion and consistent GUI behaviour much better. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 10:45, Daniel Reurich wrote: On 05/01/16 11:33, Daniel Reurich wrote: On 04/01/16 06:52, Go Linux wrote: Why are you merging the debian, backports and dmo repos? Is there a way to separate them? I have rarely used backports and always downloaded what I need from dmo when I first install and then disable it. dmo can really break things if you're not careful. We are currently merging dmo - was mostly done as a test for amprolla. I can ask nextime to remove that if it is causing breakages or other problems. Update: I have raised an issue about no longer merging dmo. There are a bunch of other reasons for removing it as well - but I won't discuss them here. Presumably the very same reasons that always prevented debian from including the convenient stuff in dmo in the first place (and caused mint to have a couple of versions). Users must add them independently if they wish too ... perhaps via dmo if that repo covers their needs, or via applications offering .deb downloads directly from their site. But aside from that look at the long long history of debian multimedia issues, users complaining of sudden breakages in debian packages, fixed by "remove dmo and load the debian libraries that the package was built against instead". Perhaps also the very very problematic relationships involved, over a very long time. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Question about the merged repos
On 05/01/16 10:45, Daniel Reurich wrote: Update: I have raised an issue about no longer merging dmo. There are a bunch of other reasons for removing it as well - but I won't discuss them here. Thank you very much for that. Simon ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Giving Devuan sans-initramfs capabilities
On 05/01/16 08:10, Svante Signell wrote:
On Mon, 2016-01-04 at 20:43 +, Rainer Weikusat wrote:
k...@aspodata.se writes:
chaosesquet...@cock.li:
I don't understand the desire to change it at all.
See UsrMerge discussion on debian-devel. They wan to move most stuff in / to
/usr and make it readonly. (The only sensible motivation I've found so far is
for NFS, but how many people use that?
It would seem to be a potentially useful tool in managing a fleet of locked-down
desktops with the end users prevented from modifying their system.
It would also be helpful if a vendor wanted to sell locked-down desktops without
root access, the way Samsung does very profitably with their android systems ...
using selinux to limit what the user can do ('owner' doesn't seem an accurate
word for the person who acquires such a device, while that system remains in place).
Or perhaps set up a flock of virtual servers with shared read-only systems.
All of which are the kind of use-cases the people pushing the changes in debian
hope to make $$$ from, and they are real and valid use-cases. But they are all
the exact opposite of the original motivation for debian, GNU and everything
most people here believe in. Instead those use-cases should be developed and
maintained within the corporate budgets that hope to profit from them, within
their own distributions ... Red Hat, Canonical etc.
It is very grim that Debian has allowed itself to be co-opted as a cheap
resource for those companies, but really I do not believe that will be the
outcome ... more likely it will just be knackered in a way which leaves less
choice for the less sophisticated end user and persuades more open source
developers to focus on making their work fully compliant with those corporate
oriented distributions. Fantasies of becoming the android of the desktop, with
app stores and advertising revenue flowing in their direction. Not likely, the
direct consumer market is already taken, by Samsung, Apple, Google, Facebook etc
... and they have much much bigger resources to deploy in keeping it.
Simon
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
