> 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.
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
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
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.
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 poss
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 sy
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 ?
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
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-R
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 tha
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.
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 descri
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 - shoul
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 t
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 minut
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 t
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
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 t
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...
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
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.
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
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
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 yo
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 th
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
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 anoth
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 general
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
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 minute
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, bu
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
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
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 sus
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 becau
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
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 accepte
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 y
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 t
hough 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 Ho
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 im
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
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 abou
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'
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,
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
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 plu
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 los
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
> i
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 aft
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 3
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
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,
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 BI
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
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
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 inje
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
>
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
Hendrik Boom wrote:
>> An experienced sysadmin who has to do this type of thing several times a
>> day would have designed this syntax for ease of use. The systemd
>> developers did not do this, presumably because they do not have to type
>> these commands several times a day.
>
> I would no
Rainer Weikusat wrote:
>> That's what I've always assumed - and IMO it seems like a sensible
>> idea. After all, people don't generally object to the idea of programs
>> calling various libraries instead of "doing their own thing".
>
> Well, I certainly do object to this idea: Each program still
On 9 Jan 2016, at 17:02, Stephanie Daugherty wrote:
> 5 - have udev issue manual (admin-chosen) persistent names by mac address
Which, IMO, is the most logical option.
Lets face it, how often do people actually change hardware ? And when hardware
is changed, it's a trivial task to do the one-o
Ozi Traveller wrote:
> There's certainly a pause when boot, if my modem hasn't quite connected.
>
> And if I start the modem first, so it's connected properly, then it just
> boots.
That could be something much more mundane.
If you have no internet connection, or worse, and IP address but no
Ozi Traveller wrote:
> I also have a couple of non-systemd box connected to the same modem, and they
> boot to a desktop without the wait.
It's probably not systemd vs non-systemd. While it does cause me a bit of a
choke to defend systemd, it's probably not specifically systemd that's causing
Ozi Traveller wrote:
> Debian Jessie boot the slowest.
Ah, that'll be because of stuff that hasn't been "improved" into systemd yet
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Arnt Gulbrandsen wrote:
> By now, the concept of unprivileged local users is a little obsolete anyway.
>
> Today, hosts generally serve only one unix user, there generally is only one
> local user of one host, and that local user is the user that owns everything
> valuable. So is the a real po
Didier Kryn wrote:
> I don't think Grub2 is all about pretty colours though. The veteran admin
> likes to have a bootloader which is easy to configure, but the random admin,
> likes to have a working multi-boot bootloader at the end of the installation.
Indeed, and when ${random_admin} has a m
Rainer Weikusat wrote:
> The commands which are actually executed via these S- and K-links come
> from individual packages and ultimatively contain whatever the people
> responsible for that considered sensible. Which is usually a pretty
> arbitrary assortment of more or less useless code which a
Rainer Weikusat wrote:
>> - Some headers to tell utilities what runlevels the service should run
>> at, and dependencies.
>
> That's a LSB invention. It's a grotesque travesty as it uses 'magic
> comments' to embed a declarative mini programming language in an init
> script which is only ever us
Didier Kryn wrote:
>It's absolutely amazing that one can be a Debian developper and a member
> of Microsoft in the same time. Yes, that's an ethical break down of the whole
> Debian project.
I think some people are reading more into this than they should.
There is no reason whatsoever that
Daniel Reurich wrote:
> perhaps doing the same thing as init-system-helpers dh_systemd package
> to add support for runit into each respective package.
That's the logical way to do it - the init script(s) should be part of the
package. The downside of that is the requirement for every package m
KatolaZ wrote:
> Well, not everybody pays his bills developing open source software,
> but if I were a Debian developer, who had adhered to the debian Social
> Contract [1], I would find it difficult to organise a fest to
> celebrate Microsoft offering Debian as an option on its
> azure-whatever.
dev1fanboy wrote:
> So for having our own values we are a "hardcore cult", how dare we voice our
> opinions or stand up for our values (like anyone else in the free software
> community, btw). Better yet, let's go back to debian because otherwise we're
> elitists.
That's not what I said - a
Mat wrote:
>> That's the logical way to do it - the init script(s) should be part of the
>> package. The downside of that is the requirement for every package
>> maintainer (team) to understand and support multiple init systems - or for
>> someone supporting an init system to become a maintain
Mitt Green wrote:
> They can request a refund before activating the
> license, but will actually receive a smaller amount of
> money than they spent, if some at all at all.
I recall reading how one person, after a fight to get anything, got much more !
This isn't the case I was thinking of, but
Robert Storey wrote:
> Since the Mac doesn't have a ctrl key, the following was a particularly
> relevant post:
Really ?
Mine does, there between the fn and alt keys - standard UK keyboard on a
MacBook Pro. I think it will be model/keyboard specific. You can always plug in
a different keyboar
Robert Storey wrote:
> So maybe I should ask: Have you tried installing Linux on your MacBook? If
> so, how was the experience? Any advice about that? Any nonsense to deal with
> similar to Microsoft's "secure boot"? (if you answered those questions
> already in another post, I"m sorry, I miss
William C Vaughan wrote:
> I have been flamed before because of my posts on this mailing list
That's inexcusable.
> I think that ultimately, EFF or the GNU folks will need to pursue lobbying
> for legislation to prevent hardware companies from imposing restrictions upon
> software installs by
Wim wrote:
> I still have my previous model, I suppose I ought to try a native install on
> it - and perhaps see if I can get OS X running as a VM.
>
> I would prefer dual booting personally, since running OSX in a VM isn't
> always perfect. Fi, access to external hardware over USB, like audio
Wim wrote:
> I would take a look at that SATA cable AGAIN. These break far too often. And
> when they break, they often don't break completely. Symptoms vary from weird
> boot problems, to the OS going corrupt, to a general slow drive.
No, definitely a "hard" fault. While trying to deal with i
richard lucassen wrote:
> I'm very pleased to see that someone is building a libsystemdfree xorg.
> But what about security updates? And what about future versions? Who is
> going to do that? What about the robustness of Devuan? Don't get me
> wrong, I really like the Devuan project, but wouldn't
richard lucassen wrote:
> I'd rather go for a, like Tobias suggested, a libsystemd telling
> the package that is linked against, that it runs on a non-systemd
> system.
> But maybe that solution is too simple, clear and wrong.
I think it's a *possible* solution and has certain attractions - but
Florian Zieboll wrote:
> For the fun of it, I just ran an "apt-get install --install-recommends
> --no-install-recommends" and it chose to not install the recommends.
> The same with contradicting lines in apt.conf(.d/*):
>
> APT::Install-Recommends "0";
> APT::Install-Recommends "1";
>
> Thi
Jaromil wrote:
> meanwhile, on the background, the usual bullying goes on among the
> systemd hooligans, sarcastically liquidating the concern with some
> cynical remarks, as if it would be a deserved punition for users
> caught into a bricked laptop rather than an erased filesystem:
>
> http://
Rainer Weikusat wrote:
> There are really only two options:
>
> 1. Don't mount or mount r/o and require user interfaction prior to
> working with these variables.
>
> 2. Mount r/w and expect people messing around with the fs as superuser
> to know what they're doing.
Or the third option -
Rainer Weikusat wrote:
>> Or the third option - mount r/o and remount r/w when needed.
>
> As I wrote in the original text, that's a extremely bad idea because
> this means it may suddenly be affected by an already running command
> never supposed to work with it.
The window for that must be "v
Rainer Weikusat wrote:
> Dave Turner writes:
>> There seems to be an assumption that everybody is a 'power user' and
>> knows exactly what they are doing.
>> The reality is not like that at all.
>> Leaving nasty surprises for the unwary and inexperienced is at worst
>> malicious and at best inco
Didier Kryn wrote:
>> for the real "general case",
>> someone who blindly trusts the advice of strangers despite he doesn't
>> understand it will end up getting himself in trouble sooner or later and
>> probably rather sooner than later.
>
>Eg nearly any client of a physician, a lawyer...
:
Rainer Weikusat wrote:
> "Whoever disagrees with me MUST either have a hidden, maliscious agenda
> or be out of his mind" is a pretty standard way to (attempt to) handle
> a situation where someone ran out of arguments but doesn't feel like
> admitting that.
Not at all. I have a perfectly sound
Arnt Karlsen wrote:
> ..me, I do not see any point in keeping it mounted at all.
> Whenever such a need arises, it should be mounted read-only.
> If a need to write to /sys/firmware/efi/efivars should happen,
> the machine should first be taken off-line, backed-up etc out
> of production and int
Rainer H. Rauschenberg wrote:
> I think this is the road that led to systemd -- if you think Linux needs
> to be "as easy as Windows" you tend to take away all the aspects that made
> it superior (in my view).
I think I didn't really express my position very well.
I'm not advocating "taking al
KatolaZ wrote:
> I don't get why any of those occasional "sysadmin-wannabe" users you
> have described above would ever need to mess around with their UEFI by
> hand.
They don't. But certain tasks they run apparently can do - did someone mention
Grub updating it ?
So one scenario (which I thin
Rainer Weikusat wrote:
> But "the hardware" didn't "break". Certain vendor-supplied software
> reportedly ceases to function if certain EFI variables are deleted.
That is the sort of linguistic gymnastics that vendors use to get out of
accepting responsibility for stuff.
I think most people wou
Steve Litt wrote:
> You'd be hugely surprised at how literally some states in the US
> interpret contracts. I live in (anti-employee) Florida, and a friend of
> mine here in Florida was advised by his lawyer to not work for Linux for
> the next 6 months because his former employer had a 6 month
>
Rainer Weikusat wrote:
> The abstract definition of 'runlevel' is (as far as I'm aware of it):
> "Set of processes supposed to be running".
That's what I understand it to be.
> Considering this, one can
> safely conclude that whatever 'Dennys' did, he certainly didn't to
> that. A somewhat educ
Matthew Melton wrote:
> What you are describing is a state machine?
> Each run level is a stable state representing what is running (or supposed to
> be). Something needs to trigger (change of input or "change of runlevel")
> Each stable state has an "init" transition state (starting the servi
KatolaZ wrote:
> The vast majority of people I know who work with Linux
> servers are doing the best they can to keep old Wheezy intallations,
> and those who can't are switching to something else (either Devuan, or
> other systemd-free distros, or FreeBSD).
>
> I admit that my (very restricted)
Brad Campbell wrote:
>> But then I still have Squeeze and Lenny systems running (they aren't broken
>> ...) - don't think I have anything older than that !
>>
>
> I just bumped up against a problem with a squeeze system. It's ppc, and
> everyone has dropped the non-x86/x64 archives. That made
Arthur Marsh wrote:
> Doesn't snapshot.debian.org keep up until the last released versions of
> packages, including for architectures no longer supported? (Admittedly one
> would need to use packages.debian.org to find out what was the last supported
> version of a package for a different arch
Go Linux wrote:
> As did mine. And then a genius of an udev developer took care of it and made
> sure that the cameras ID_TYPE changed from "disk" to "generic", so no user
> but root could use the camera. Now it works again, but ...
Are, what you mean is "it worked until some genius *fixed* it
1 - 100 of 428 matches
Mail list logo
