Re: [DNG] Quick start guide to uprading to Devuan and configuring minimalism

[Alexander Bochmann]

...on Thu, Nov 05, 2015 at 11:10:49AM +0100, miro.ro...@croatiafidelis.hr wrote:

 > it is possible to use a testing kernel on the Devuan Stable Jessie 1.0,
 > to then compile and deploy grsecurity-hardened kernel, much like I was

Didn't actually try that on Devuan yet, but I wouldn't expect 
any problems unless you forget to configure in something essential...

I have Wheezy running on 4.2.x-grsec kernels, and besides the usual 
suspects that need some pax flags (java, iceweasel), everything works. 
Ah yes, /usr/sbin/grub-probe needs to have MPROTECT disabled, too.

Alex.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] A Devuan install CD

[aitor_czr]

What are you referring to exactly? The tutorial of dev1fanboy explains 
how to upgrade from debian whezzy to devuan jessie, and the resulting 
system will depend on the original system.


There aresome livecds of devuan available, neigther of the being hosted 
in the website of devuan, since they are not official images. But i can 
build **exact**replicas** of Devuan in i586, i686-pae and amd64. I would 
be delighted to do so, if people are interested. The images could be 
uploaded to devuan.org with the approval of VUAs, of course.


Cheers,

   Aitor.

On 11/07/2015 11:23 AM, "Scienceof Atomics"  
wrote:

A quick thought.

Would it be possible and/or desirable for the end result of the dev1fanboy
process to be captured as an image and used to create a short Devuan
Install CD (not DVD)?

This probably belongs on the Devuan website, but I've been following this
mailing list because of mutual interest.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Arnt Gulbrandsen]

Steve Litt writes:

I'd like to discuss this. Now, after a year of thought, I still see no
benefit to "starting servers in parallel" except for boot time.


Because you're thinking of the happy path.

Suppose you have a few dozen servers on three continents, providing a 
user-facing service, using something like zk or etcd to coordinate the 
servers.


Suppose further that something on the servers does five DNS lookups at 
startup. On the happy path that takes 5*0.008=0.04 seconds and who cares, 
but the worst case is in minutes. Say five 90-second timeouts. If things 
start up serially, zk or etcd will begin to initialise about eight minutes 
after the server started booting. The cluster can be without a quorum for 
eight minutes, and if you're lucky that's just a horrible backlog of failed 
or blocking transactions. If you're unlucky the node has been declared 
unhealthy and the cluster has started copying terabytes of data in order to 
restore redundancy.


For want of an X, Y. In real life ;)

BTW, systemd's approach to parallelism isn't particularly good for this 
sort of service. Parallelism is good, but not just any kind. Systemd thinks 
it can start services according to a DAG, but in reality that DAG is not 
knowable on any single host. For example: Service X on nodes 1-A8 needs 
service Y, which runs on nodes 3-5 and 12-15 today. The only sensible 
approach is to start everything and require that all services behave 
robustly when a dependency isn't ready.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Steve Litt]

On Thu, 05 Nov 2015 19:05:23 +
Rainer Weikusat  wrote:

> Worrying about 'starting servers in parallell' only makes sense if
> there's a real-world situation where this demonstrably makes a
> relevant difference. And I very much doubt that --- that's just
> another imaginary sugar-coating supposed to help selling systemd to
> people who are not expected to understand the issue. As someone
> recently wrote,

I'd like to discuss this. Now, after a year of thought, I still see no
benefit to "starting servers in parallel" except for boot time. There
are use cases where boot time is critical (99.% uptime, or a
television appliance), but for the vast majority of us the difference
between a 1 second boot and a 40 second boot is we get a chance to go
get a cup of coffee every day, week, month, year, whatever. And
frankly, it's been a long time since I've seen any system that takes
more than 30 seconds to boot.

If they were honest about it, they'd say "use systemd if boot speed is
a real priority for you, otherwise use whatever you want." But n,
they sell parallel instantiation as a feature the way the car industry
tempts us with keyless ignition and magnesium paddle shifters.

I'm a big fan of the Epoch init system, which is a guaranteed one
service at a time sequential init system. With Epoch, the system's going
to boot the same way every single time.

I'm also a fan of Runit, because it's very daemontools like. I don't
know whether Runit parallel instantiates, but I do know it starts
services indeterminately. In practice this hasn't been a problem ---
I've been using Runit for a month on three machines, some of which I
booted quite often (8 to 14 seconds grub prompt to Virtual Terminal,
with complete networking). With Runit or any other daemontools-inspired
init or process supervisor, if process dependencies become a problem, a
simple test script in the directory of the process needing the
dependency, to test that the dependency is *really* open for business
(and isn't just backgrounded) solves the problem.

Here's honest marketing for parallel instantiation: "Parallel
instantiation is great because it reduces boot time from 10 to 20
seconds to 1 to 4 seconds, assuming it's implemented right. If you
reboot every day, the time you save would give you 1/2 of one trip to
the drinking fountain."

> 
>   Point remains: most of the "less-tech-savy" users will
> probably not even know what systemd is, or what the fuss is all
>   about. It's all been seamless, without hitch. The OS boots and
>   gives them a GUI, done.
> 
> IOW, without the systemd marketing barrage, most people had never
> noticed it as there are no user-visible difference, IOW, it's not an
> improvement for them.

Yes it is. Now the most tech-challenged user can feel superior to
somebody (us). Now the dumbest droob can call us "neckbeard", "troll",
"scared of change", "1985", "demotivating", and "just don't
understand." Think how fun that is for the guy who's usually the
dumbest guy in the room.

And systemd did something for *us* too. It got those clowns out of our
hair. Systemd is a honeytrap. :-)

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
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]

Le 06/11/2015 18:28, Simon Hobson a écrit :

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 !


I am booting my servers, say, once per year,  but my laptop at 
least twice per day. Booting a server takes long, for the reason Rainer 
says; I don't care much except when there's an issue I need to debug. 
For the laptop I definitely prefer to shut it down before I put it into 
my bag to take the metro.


On the servers I have more or less big RAIDs made of 
electro-mechanical disks; on my laptop an SSD. Disk access contention 
cannot be the same for SSD and electro-mechanical disks, specially when 
you only read.


And there is yet other categories of Linux devices: the embedded 
and hand-held...


Le 06/11/2015 19:37, KatolaZ a écrit :

Please do not tell the systemd guys that the bios PXE boot takes so
much time to do its work, otherwise they will go head down to replace
it with their own parallel-faster-more-reliable-memory-eating
systemd-PXEbootd.


Maybe the ultimate reason for Systemd is it was a condition posed 
by M$ to provide RedHat on Azure. In which case we talk of virtual 
machines, and I expect they don't emulate PXE boot :-)


Didier

___
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

[Jaromil]

Dear Sam,

On November 7, 2015 7:07:22 AM GMT+01:00, Sam 
>Thanks again, but I fear that when folks on the other side of the world
>wake up and read about these exploits, I'll be given a stern dressing
>down for brazenly and recklessly mucking-up the stable/testing/unstable
>canon...

such an attitude will find no place in this
camp, for we are all here in mutual respect
of the many different things we like to do
with our computers, not to be told what

Thanks for sharing your adventures

indeed the kernel is still Debian's
we have no plans nor need to substitute
that with our own build ATM

but won't be a problem if needed
(For instance removing kdbus)

Ciao

___
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

[Didier Kryn]

Le 07/11/2015 11:02, dev1fan...@use.startmail.com a écrit :

All that info is right as far as I can tell.

gcc versions from /proc/version are labelled as debian for me too.



The kernel remembers who has compiled it, when, and where. If you 
compile it yourself you'll be pleased to see your username in 
/proc/version. You can also add some tag to the kernel version It is 
also possible to add some tag to the version of gcc if you compile it 
yourself, and it will appear when you invoke 'gcc --version'.


As long as Devuan keeps Debian packages for kernel and gcc, you're 
going to see that they have been compiled by Debian devs. And Devuan, 
for the moment only modifies packages which need to, in order to get rid 
of systemd dependency. This does not involve gcc, and not yet the kernel.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan on top of OpenVZ

[Jaromil]

Dear Hoshpak and Emiliano

On November 6, 2015 7:45:31 PM GMT+01:00, Hoshpak  
wrote:
>Hi Emiliano,

>The best and probably only way to get Devuan working in a OpenVZ-VPS
>would be if someone built an OpenVZ-template for it.

It may be very easy to fork the OpenVZ 
template of Debian Wheezy, if they
had one, didn't they?

Ciao

___
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

[dev1fanboy]

All that info is right as far as I can tell.

gcc versions from /proc/version are labelled as debian for me too.

Try cat /etc/devuan_version

Also try switching to the stock 4.x kernel that comes with testing, you 
can do it by installing linux-image-amd64 package which I guess you 
don't have. Watch carefully the output though, I managed to mess up my 
testing system that way because I didn't notice it wanted to remove 
things, which was due to dependencies not having the right version yet 
which I think is happening occasionally.


But it looks like you migrated properly :-)

There's probably several solutions somewhere to purge old configuration 
files for packages already removed, or maybe /etc/debian_version should 
be there too idk.

 
 

Hello dev1fanboy, and everyone else.

This is just an F.Y.I. I'd like to let you know that I've just 
carried

out what so far appears to be a successful Debian -> Devuan
conversion. You prudently advised that the
upgrade/transformation/conversion should be from either Debian Wheezy
or Jessie, and that was for very good reason. However, my Debian
system was of the Stretch/Sid flavour:

/etc/debian_version
stretch/sid

/proc/version
Linux version 4.1.0-2-rt-amd64 (debian-ker...@lists.debian.org) (gcc
version 4.9.3 (Debian 4.9.3-3) ) #1 SMP PREEMPT RT Debian 4.1.6-1
(2015-08-23)

Alas, I am far too impatient, impetuous and imprudent to methodically
downgrade my system to the appropriate level before I attempted such 
a

foolish thing, so I proceeded regardless. I even went so far as to
configure minimalism in the system as you suggested, and that almost
went off without a hitch. I say almost, because in the process my
nvidia graphics driver and kernel module were trashed. But 
reinstating

those was in principle easy owing to the brilliant SGFXI script,
however I did need to re-boot (sorry KatolaZ) into a non-real-time
pre-emptive kernel (i.e. non -rt-) otherwise the the sgfxi script
complained and barfed.

I can provide more detail if you're curious, but for the minute, I
just wanted to thank you for your exceptionally clear and 
prescriptive
instructions and perhaps to say that, if one is as brave or foolish 
as

I am, it is eminently possible to jump across to Devuan from Debian
Stretch/Sid by following your guide.

Cheers,
Sam


p.s. there is (at least?) one annoying relic of the old Debian system
lingering on my new Devuan OS, however: /etc/debian_version still 
says

stretch/sid, and /proc/version now says:

Linux version 3.16.0-4-amd64 (debian-ker...@lists.debian.org) (gcc
version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3
(2015-08-04)

Is my triumphant declaration of success premature?




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Radeon HD 7500M/7600M [Thames] and Intel HD duo

[Mitt Green]

Hi everyone,

So I wrote to debian-user but received no answer, maybe will
have some luck here, since I am using Devuan.
Or maybe you will point me to the‎ right place to ask.

I am having a trouble with Radeon support. I am using a custom 3.18.20 kernel
(with everything unnecessary - and, as far as I see, something necessary - 
removed).

I can't play 4k videos (sometimes even fullhd) smoothly, CPU goes up to 100%
and remains there until the video is stopped. With hd (720p) CPU usage is about 
70%.

I have Core i5, dual-core with four
threads, integrated Intel HD (4000 I believe), AMD Radeon Thames [7500M/7600M].

Previously I wasn't using AMD/ATI setting in kernel config, nor GPU switching,
I feel that Intel GPU is fairly well alone, unless you want to do something 
heavier
like those 4k videos.

I tried some LiveCDs just to make sure that the problem is in system config,
not from the hardware side which isn't that weak; I was able to decode those 
UltraHD mp4s in LiveCD sessions.

I've tried enabling ATI Radeon, installing firmware-amd-graphics (by the
way the only thing I need from there is TURKS_pfp.bin), putting these things
together, result is the same as with Intel HD solo, except for higher RAM
consumption.

Here's the paste of my current Intel-only config: 
http://paste.lisp.org/display/158650

Any help will be highly appreciated.

Thanks,

Mitt
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] NVidia driver howto?

[hal]

hal wrote on 09/03/2015 06:17 AM:
> alias nvidia nvidia_340
> alias nvidia-uvm nvidia_340-uvm

Just a follow up on my eariler post about nvidia drivers (months ago).

I had to remove these two lines today from my 
/etc/modprobe.d/nvidia-graphics-drivers-ubuntu.conf file. I rebuilt the nvidia 
driver and it borked when trying to insert the new module:

modprobe: ERROR: ../libkmod/libkmod-module.c:816 kmod_module_insert_module() 
could not find module by name='nvidia_340_uvm'
modprobe: ERROR: could not insert 'nvidia_340_uvm': Function not implemented

As it turned out, the two lines above referencing nvidia_340 were in conflict 
with the latest nvidia 352-55 driver. Commenting them out allowed the module to 
build succesfully. Hope it helps someone else.
___
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

[miro . rovis]

On 151107-12:06+0100, Alexander Bochmann wrote:
> ...on Thu, Nov 05, 2015 at 11:10:49AM +0100, miro.ro...@croatiafidelis.hr 
> wrote:
> 
>  > it is possible to use a testing kernel on the Devuan Stable Jessie 1.0,
>  > to then compile and deploy grsecurity-hardened kernel, much like I was
> 
> Didn't actually try that on Devuan yet, but I wouldn't expect 
> any problems unless you forget to configure in something essential...
> 
> I have Wheezy running on 4.2.x-grsec kernels, and besides the usual 
> suspects that need some pax flags (java, iceweasel), everything works. 
> Ah yes, /usr/sbin/grub-probe needs to have MPROTECT disabled, too.
> 

Great to know!

I can't tell you how much I'd like to try it, and resume teaching
newbies grsecurity hardening, only in Devuan. But, poor health and other
problems...

Also, I'm really happy to see that you cater for users who want no-dbus
(nor other poetterware). Recommended you the other day over on Gentoo
Forums (like that I haven't already in many occasions spoke about my
hopes in the Devuan projects):

Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-t-992146-start-75.html#7837424
(just search for string Devuan)

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


signature.asc
Description: PGP signature
___
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]

Le 07/11/2015 15:26, Steve Litt a écrit :

for the vast majority of us the difference
between a 1 second boot and a 40 second boot is we get a chance to go
get a cup of coffee every day, week, month, year, whatever. And
frankly, it's been a long time since I've seen any system that takes
more than 30 seconds to boot


Why the hell did they invent suspend-to-disk? And why are you using 
it? Arent' you?


I'm afraid I've spent more time in this thread than in booting 
laptops in a whole year.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Packaging vdev

[aitor_czr]

Hi all,

I just started with fskip:

http://gnuinos.org/vdev/

It builds successfully, but after a installation i saw the following 
issue: all the /usr/lib/*.o files are missing !!


Cheers,

   Aitor.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Arnt Gulbrandsen]

Miles Fidelman writes:
Not for nothing, but if you're coordinating distributed 
servers, your system design is WAY too closely coupled if boot 
time effects anything.


Boot time is just a kind of downtime. If downtime lasts too long, the 
health checks declare nodes bad and expensive recovery starts.


Arnt

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Miles Fidelman]

On 11/7/15 9:26 AM, Steve Litt wrote:

On Thu, 05 Nov 2015 19:05:23 +
Rainer Weikusat  wrote:


Worrying about 'starting servers in parallell' only makes sense if
there's a real-world situation where this demonstrably makes a
relevant difference. And I very much doubt that --- that's just
another imaginary sugar-coating supposed to help selling systemd to
people who are not expected to understand the issue. As someone
recently wrote,

I'd like to discuss this. Now, after a year of thought, I still see no
benefit to "starting servers in parallel" except for boot time. There
are use cases where boot time is critical (99.% uptime, or a
television appliance), but for the vast majority of us the difference
between a 1 second boot and a 40 second boot is we get a chance to go
get a cup of coffee every day, week, month, year, whatever. And
frankly, it's been a long time since I've seen any system that takes
more than 30 seconds to boot.




Boot time better NOT be critical for high availability situations. Any 
reasonable systems designer uses hot sparing & failover to achieve high 
uptime.  Everything had better already be booted on the failover system.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Miles Fidelman]

On 11/7/15 10:04 AM, Arnt Gulbrandsen wrote:

Steve Litt writes:

I'd like to discuss this. Now, after a year of thought, I still see no
benefit to "starting servers in parallel" except for boot time.


Because you're thinking of the happy path.

Suppose you have a few dozen servers on three continents, providing a 
user-facing service, using something like zk or etcd to coordinate the 
servers.





Not for nothing, but if you're coordinating distributed servers, your 
system design is WAY too closely coupled if boot time effects anything.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

___
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]

Arnt Gulbrandsen  writes:
> Steve Litt writes:
>> I'd like to discuss this. Now, after a year of thought, I still see no
>> benefit to "starting servers in parallel" except for boot time.
>
> Because you're thinking of the happy path.
>
> Suppose you have a few dozen servers on three continents, providing a
> user-facing service, using something like zk or etcd to coordinate the
> servers.
>
> Suppose further that something on the servers does five DNS lookups at
> startup. On the happy path that takes 5*0.008=0.04 seconds and who
> cares, but the worst case is in minutes. Say five 90-second
> timeouts.

A simple solution to this problem would be: Ensure that 'servers' don't
daemonize themselves but start them all with the help of a tool
performing this. Since all 'server code' will then be executed from the
forked process, startup can immediately move on, effectively
parallellized without any additional effort.

NB: This is restricted to the task itself and it doesn't bother with the
'ensure no controlling terminal can ever be acquired again' part of the
procedure the FatDoorstop wrecking crew ripped out of APUE in order to
help marketing their "engineering marvel".

--
/*
  Daemonize a process. Unless -n is passed as first argument,
  all open files will be closed and descriptors 0, 1 and 2
  associated with /dev/null prior to executing the actual
  command.

  Copyright (C) Rainer Weikusat 2015

  Free to use according to the conditions set out in GPLv2
  or any later version.

$Id: daemon.c,v 1.4 2015/11/07 16:44:11 rw Exp $
*/

/*  includes */
#include 
#include 
#include 
#include 
#include 
#include 

/*  macros */
#define FDS "/proc/self/fd"

/*  variables */
static int setup_fds = 1;

/*  main */
static int die(char const *sysc, char const *fnc)
{
syslog(LOG_ERR, "%s: %s: %m(%d)", sysc, fnc, errno);
exit(1);
}

static char **parse_args(char **argv)
{
char *s;

s = *++argv;
if (*s == '-' && s[1] && !s[2])
switch (s[1]) {
case 'n':
setup_fds = 0;

case '-':
++argv;
}

return argv;
}

static void close_open_fds(void)
{
struct dirent *d_ent;
char *endptr;
DIR *dir;
int dir_fd, fd;

dir = opendir(FDS);
if (!dir) die(__func__, "opendir");
dir_fd = dirfd(dir);

while ((d_ent = readdir(dir))) {
fd = strtoul(d_ent->d_name, , 10);
if (fd != dir_fd && !*endptr) close(fd);
}

closedir(dir);
}

static void do_fd_setup(void)
{
close_open_fds();

open("/dev/null", O_RDWR, 0);
dup(0);
dup(0);
}

int main(int argc, char **argv)
{
char **cmdv;

/* stop reinventing logging systems */
openlog("daemon", LOG_PID | LOG_PERROR, LOG_DAEMON);

if (argc == 1) {
syslog(LOG_NOTICE, "Usage: daemon [-n]  *");
exit(1);
}

cmdv = parse_args(argv);
switch (fork()) {
case -1:
die(__func__, "fork");

case 0:
break;

default:
_exit(0);
}

setsid();
if (setup_fds) do_fd_setup();
execvp(*cmdv, cmdv);

die(__func__, "execvp");
return 0;
}
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] A Devuan install CD (aitor_czr)

[Scienceof Atomics]

aitor_czr wrote:

What are you referring to exactly?


A purely personal goal that I'll describe briefly by way of illustrating  
the spread of end-user interest.


I've just purchased a 13-DVD set of Debian Jessie, and also burnt myself a  
copy of ExeGnuLinux, which combines Debian with the Trinity project,  
aiming to keep alive the KDE 3.5 desktop:


http://exegnulinux.net/

EGL is planning a move to Devuan, which is how I found out about it, but  
is presently in a halfway state. I now have a complete software suite that  
should last indefinitely into the future, given two contingencies:


1. A move from 32-bit to a duplicate 64-bit DVD set when my ancient boxes  
eventually fall over.


2. Occasional kernel upgrades and driver installs to accommodate new  
hardware.


There are many who will view this not merely as conservative, but as a  
case of rigor mortis. The thing is, I'm interested in USING the software  
for creative and productive work, not just endlessly fiddling with  
eye-candy and invisible technological "improvements". Apps that I use  
include:


1. Electronic design: xcircuit, pcb, picprog, spice and others.
2. Music: hydrogen, audacious, audacity, denemo, rosegarden, sox, timidity  
and others.

3. Image: gimp, blender, cinelerra and others.

Along with the usual libre-office, gnumeric, nedit, opera and the rest of  
the daily round, most of these represent a large investment in time and  
effort in order to achieve productive competence. The VERY LAST thing I  
need is endless invisible changes to the underlying system that require me  
to run flat out in order to stay in the same place. This is the main  
reason I started with Linux more than a dozen years ago, and why I want it  
to remain manageable by those with moderate technical skills.


The systemd crowd will end up as a cabal of High Priests owned and  
controlled by the TransNational Corporations overseeing an OS consisting  
of a few monster binary blobs that only they have the time and experience  
to comprehend. The Micro$oft/SCO debacle of years past did not mark the  
end of efforts at corporate take-over of Linux, merely a move to a more  
subtle, longer-term agenda.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] A Devuan install CD.

[dev1fanboy]

One way you could do things is to debootstrap the hosts using the 
Devuan Install CD.


It's not for the faint hearted but I'd suggest install once and upgrade 
on each stable release.


To get some tips on what that might involve you can see this 
(unfinished) document:


https://git.devuan.org/dev1fanboy/Upgrade-Install-Devuan/wikis/upgrade-with-wheezy-minimal-install

I was originally going to post this as the install guide (luckily found 
a copy on disk), but since Devuan installer CD is working some of it 
was not relevant to Devuan, others parts were optional. You'll have to 
adapt it and I suggest using it with with care as I planned to test 
this before posting.


 
On Saturday, November 7, 2015 6:44 AM, Scienceof Atomics 
 wrote:

 

A quick thought.

Would it be possible and/or desirable for the end result of the 
dev1fanboy  
process to be captured as an image and used to create a short Devuan 
 

Install CD (not DVD)?

This probably belongs on the Devuan website, but I've been following 
this  

mailing list because of mutual interest.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Detailed technical treatise of systemd

[Miles Fidelman]

On 11/7/15 12:47 PM, Arnt Gulbrandsen wrote:

Miles Fidelman writes:
Not for nothing, but if you're coordinating distributed servers, your 
system design is WAY too closely coupled if boot time effects anything.


Boot time is just a kind of downtime. If downtime lasts too long, the 
health checks declare nodes bad and expensive recovery starts.




Actually, in my experience, the problem is when downtime is too short, 
and worse, when things flap.  With a hot failover process, once one has 
failed over, one wants to wait a long time before failing back to the 
primary system.  Otherwise there's a serious risk of flapping back and 
forth - which is REALLY expensive.  One wants lots of hysterisis in the 
system.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng