From: nospam@example.net   
      
   On Thu, 27 Feb 2025, Salvador Mirzo wrote:   
      
   >> Excellent! I wonder if it can replace mbsync nicely as well? Would be nice   
   to   
   >> have fdm handle both my mbsync (so sync imap folders to local laptop) _and_   
   to   
   >> take care of news posts! I can easily see how the filters would take care of   
   >> sorting the posts from various newsgroups into their respective folders in   
   my   
   >> mail client.   
   >   
   > I'm not a user of mbsync, but if you use mbsync just to download mail   
   > from an IMAP server, then certainly fdm can replace it.   
      
   Excellent! As an added bonus, I would then get off mbsync. I think the creator   
   of mbsync was woke, and changed master/slave to something I no longer remember   
   in the code, in order not to offend people. Complete nonsense!   
      
   >> As for posting, my mail client, alpine, has that covered! =)   
   >   
   > You should be good then. :)   
      
   Excellent!   
      
   >>> daemons.  But it turns out that's the only thing about systemd that I   
   >>> ever liked.  And even then I changed my opinion.  Daemons are not really   
   >>> meant to be managed by regular users; if there's any user that should   
   >>> have the right to run a daemon, then they should have sysadmin powers,   
   >>> even if specifically just for the task at hand.  Bottom line: it's a   
   >>> neat thing that it does, but it might not quite be a real need.   
   >>   
   >> I agree! That's the problem, it tries to be too neat, and to do too much.   
   In the   
   >> end you have this horrible monolithic kludge that will probably crash due   
   to its   
   >> complexity, and take the system with it.   
   >>   
   >> Another thing I intensely dislike with it is the long and convoluted syntax   
   of   
   >> the commands. I mean just look at "ls"... it's beautiful! And "l" followed   
   by an   
   >> "s"! =D   
   >>   
   >> Now look at this horrible mess: "systemctl list-timers" Yuck!   
   >   
   > Yeah---there's a fine line between incrementing language and sticking   
   > with the previous, well-established vocabulary.  That's particularly   
   > important for hackers because they have an imense amount of vocabulary   
   > to manage and great fluency is essential to their day-to-day operations.   
      
   Another example from hell for me is powershell. I've never seen such long   
   command! Microsoft powershell gurus must really enjoy typing!   
      
   >> That's good! After all, if I don't want systemd, there are distributions   
   without   
   >> it. =) The only annoying thing is that since I teach linux I am forced to   
   teach   
   >> the most common tools, and sadly that means systemd.   
   >   
   > No intention to question you here, but I'm sure you know how   
   > questionable this might be.  I would think it's not really important to   
   > teach about systemd, specially if you don't find it beautiful.  The   
      
   Sadly I have to. Every course is governed by a governance document that   
   specifies what must be taught. If a concept in that document is not taught,   
   students can complain to the government, and the school gets a mark in their   
   naughtiness register, and if too many accumulate, they can get fines.   
      
   The work around is, of course, (and I do this to some extent) that it is not   
   specified how deep one has to go into it. So a classic example was an intro to   
   linux course, where the governance document said that the students must be   
   taught how to compile their own software with configure/make/make install.   
      
   So I cover that in about 20 minutes, since it is completely out of place in a   
   short introduction to linux course.   
      
   > principles and their concrete illustrations are much more interesting.   
   > The ``everything is a file'' is an example, and you can illustrate with   
   > countless examples.  Modularity is another relevant word and can be seen   
   > at its prime in UNIX systems (and extremely in software such as qmail),   
   > with opposite examples in sendmail and also in systemd.   
      
   Very much true.   
      
   > On the other hand, I'm thinking here that you'd remark that your courses   
   > are highly practical, involved with system administration per se.  I'm   
   > aware of that.  But, still, I really don't see system administration   
   > very different from software writing.  I would not find it too important   
      
   Yes... that's the vocational school style. Short courses 4 - 12 weeks depending   
   on the subject, to get people barely up and running, and the idea is that they   
   will then learn the finer details on the job or during their job training.   
      
   When it comes to system administration in the modern sense, yes, there is an   
   overlap with being a kind of programmer. But before that stage in their   
   training, they learn how to do everything by hand, and only in a later course   
   (the cloud course) do the students get to try their hand at scripting   
   deployment   
   of containers, VM:s, and finally... the live cloud with publicly accessible   
   machines.   
      
   > to discuss the operational details of a specific system or software.   
   > Certainly a UNIX system has its own particularties in their rc scripts,   
   > but I would spend more time looking at POSIX-sh semantics, style,   
   > philosophy and history because it's primarily sh scripts that engineer   
   > the start-up schemes of UNIX systems.  Because then every hacker can use   
   > that kind of culture to investigate whatever system he's interested in.   
      
   Oh believe me... I've had to _fight_ to keep any resemblance of teaching basic   
   bash scripting in the linux course. At first students hate it, but the   
   brilliant   
   ones later on tell me that they actually picked up a lot of linux while bash   
   scripting, instead of if we used python or something else. This makes me happy   
   and works as intended! ;)   
      
   > In other words, I'd go for depth, not immediate working knowledge.   
   > Every system administrator will have to grind through the manuals   
   > anyway.  Knowing how to start or stop daemons, say, in a particular   
   > system would not be terribly useful in a classroom.  Of course, we would   
   > see how run the commands in whatever system we're using for the   
   > illustrations at the black board or at the computer lab, but merely to   
   > see things in motion.   
      
   I wish we could do that... but the amount of teaching hours and focus on the   
   vocation schools make that very difficult. =(   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)