LOoks good to me, if I understand what I'm looking at.
I'd recommend you change the name of the picklist form. Calling
it "Network Manager" would cause confusion in the marketplace, and
might lead some folks to not use it because they didn't want
NetworkManager. How bout "Pick a Network" or some s
This is a screenshot. It is not the type of Microsoft Aero designs but
it functions and it gives the necessary information while respecting
the intelligence of users.
http://s17.postimg.org/6frwnwmhb/2015_08_22_070752_1600x900_scrot.png
On 22/08/2015, Edward Bartolo wrote:
> GUI frontend is re
GUI frontend is ready.
Now, it is time for users to discover deep bugs that only show their
heads when the user number increases.
A popup window has been provided to display detailed information about
any available wifi hotspots. This simplified the design and
implementation of the GUI.
Hopefull
I think, I can also upload the Lazarus code of the frontend. I am
using the application, and for those who love the principle of "Keep
it simple stuptid", it is a nice simple application which is run on
request. It is also controlled by the user, instead of automatically
making decisions behind the
At long last, the backend runs without the frontend having for it to
finish as I wished. This got rid of frontend hangs.
On 21/08/2015, Steve Litt wrote:
> On Fri, 21 Aug 2015 06:47:13 +0100
> Edward Bartolo wrote:
>
>> Parsing headaches:
>>
>> I have this chunk of data retrieved from the back
On Fri, 21 Aug 2015 06:47:13 +0100
Edward Bartolo wrote:
> Parsing headaches:
>
> I have this chunk of data retrieved from the backend which I need to
> parse *reliably*. The goal is to read the SSID and the corresponsing
> signal strength.
>
> How should I proceed. This part of code will be do
Hendrik Boom writes:
> On Fri, Aug 21, 2015 at 12:51:55PM +0100, Rainer Weikusat wrote:
>>
>> That's going to work with this particular problem which you incorrectly
>> (the original path wasn't a macro) reduced to appending a string of
>> unknown length to a constant string. Taking this into ac
On Fri, Aug 21, 2015 at 12:51:55PM +0100, Rainer Weikusat wrote:
>
> That's going to work with this particular problem which you incorrectly
> (the original path wasn't a macro) reduced to appending a string of
> unknown length to a constant string. Taking this into account, a
> solution without s
Rainer Weikusat writes:
[...]
> #include
> #include
There's an
#include
missing here in order to make the code compile w/o warnings.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Edward Bartolo writes:
> I reorganised the C source code into header files and C code files. I
> also tested the backend to make sure the reorganisation of the code
> did not impact its functionality. I also included several 'patches' as
> suggested and made sure strcat does behave properly.
>
> N
Edward Bartolo writes:
> I reorganised the C source code into header files and C code files. I
> also tested the backend to make sure the reorganisation of the code
> did not impact its functionality. I also included several 'patches' as
> suggested and made sure strcat does behave properly.
>
> N
Isaac Dunham writes:
> On Wed, Aug 19, 2015 at 08:30:44PM +, Roger Leigh wrote:
>> On 19/08/2015 17:39, Rainer Weikusat wrote:
>>
>> >#define IFACE_TMPL \
>> >"auto lo\n" \
>> >"iface lo inet loopback\n\n" \
>> >"iface wlan0 inet dhcp\n" \
>> >"wpa-ssid %s\n" \
>> >"
On Wed, Aug 19, 2015 at 08:30:44PM +, Roger Leigh wrote:
> On 19/08/2015 17:39, Rainer Weikusat wrote:
>
> >#define IFACE_TMPL \
> > "auto lo\n" \
> > "iface lo inet loopback\n\n" \
> > "iface wlan0 inet dhcp\n" \
> > "wpa-ssid %s\n" \
> > "wpa-psk \"%s\"\n"
> >
> >
Parsing headaches:
I have this chunk of data retrieved from the backend which I need to
parse *reliably*. The goal is to read the SSID and the corresponsing
signal strength.
How should I proceed. This part of code will be done from within
Lazarus. Please, be informed that Lazarus generated GUI us
On Thu, 20 Aug 2015 22:28:45 +0200
Didier Kryn wrote:
> Le 19/08/2015 20:09, Edward Bartolo a écrit :
> > The power inherent in C is due to it not
> > getting in the way of the coder, and I like that.
>
[snip]
>
> I didn't review your code. This has been done by others anyway.
> My probl
It is becoming clear, the frontend GUI will need multithreading. I
will try to use the TThread class to derive a descendant.
On 20/08/2015, Edward Bartolo wrote:
> I reorganised the C source code into header files and C code files. I
> also tested the backend to make sure the reorganisation of th
I reorganised the C source code into header files and C code files. I
also tested the backend to make sure the reorganisation of the code
did not impact its functionality. I also included several 'patches' as
suggested and made sure strcat does behave properly.
Needless to state the obvious this c
On 20/08/2015 11:27, Rainer Weikusat wrote:
Roger Leigh writes:
On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;
p_len = strlen(IFACES_PATH);
On Thu, 2015-08-20 at 07:10 +0100, Edward Bartolo wrote:
> As it is, the frontend can connect on user request. The user can run
> the frontend application, click connect and terminate the application
> and the connection will continue to be functional. This is real KISS
> in practice but I can also
Le 19/08/2015 20:09, Edward Bartolo a écrit :
The power inherent in C is due to it not
getting in the way of the coder, and I like that.
Edward,
We cannot insist enough on this: it is an illusion, typical of the
youth, to believe that freedom = danger. Being treated of "young" is
kin
Roger Leigh writes:
> On 19/08/2015 17:39, Rainer Weikusat wrote:
[...]
>> static void saveFile(char* essid, char* pw) //argv[1], argv[2]
>> {
>> char *path;
>> FILE *fp;
>> unsigned p_len, e_len;
>>
>> p_len = strlen(IFACES_PATH);
>> e_len = strlen(essid);
>> path
Edward Bartolo writes:
> The time for repository upload is approaching...
>
> Since, I am only a humble amateur coder, I still have not figured out
> how to create a proper Debian source package. This means, I will have
> to create a tar.gz archive as follows:
>
> source-tarball.tar.gz
> |
> |
I will now organise the backend's source into separate files using
header files and source files. This to make the code more manageable
and to ease the life of anyone wanting to fork it.
On 20/08/2015, Edward Bartolo wrote:
> This is a link for the network-manager GUI running under Devuan 64 bit.
This is a link for the network-manager GUI running under Devuan 64 bit.
http://s9.postimg.org/57gjwuopr/functional_network_manager_GUI.png
On 20/08/2015, Edward Bartolo wrote:
> I am uploading a screenshot of the network manager GUI. As you can
> see, it is functional, but like anything new, I n
Regarding getting rid of requiring sudo, I vaguely remember suids are
something that have to do with file permissions. Please, could you
instruct me what I should read? Removal of sudo dependency from the
entire project is a matter of editing 2 or 3 lines in the Lazarus GUI
project. The latter is r
The time for repository upload is approaching...
Since, I am only a humble amateur coder, I still have not figured out
how to create a proper Debian source package. This means, I will have
to create a tar.gz archive as follows:
source-tarball.tar.gz
|
|---cli-backendbackend.c
|
|-
As it is, the frontend can connect on user request. The user can run
the frontend application, click connect and terminate the application
and the connection will continue to be functional. This is real KISS
in practice but I can also make the application automatically run on
startup of the OS.
Th
On Mon, 2015-08-17 at 06:48 +0100, Edward Bartolo wrote:
> The backends can be integrated into one single executable not to
> clutter the sudoers file and to increase system efficiency.
One suggestion here. Forget sudo and just make the backend suid root
like other system utilities of this type.
Hello
> Now, I should think, the buffer overruns should not be possible, but I
> am open to criticism. Buffer overruns are not something to be proud of
> and correction when taken appropriately is a blessing.
>
> Now, I will sleep as I am totally exhausted from coding all day long.
Well, you des
I have corrected the way files are saved according to what I was
suggested. I also added preventive code to cause the program to exit
whenever essid are longer than 100 characters and passwords longer
than 200 characters. The program simply issues a error message telling
why it refused to execute t
On 19/08/2015 17:39, Rainer Weikusat wrote:
#define IFACE_TMPL \
"auto lo\n" \
"iface lo inet loopback\n\n" \
"iface wlan0 inet dhcp\n" \
"wpa-ssid %s\n" \
"wpa-psk \"%s\"\n"
#define IFACES_PATH "/tmp"
static void saveFile(char* essid, char* pw)
On 19/08/2015 19:14, Edward Bartolo wrote:
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and the
third step is to correct any potential security issue
>> On 19/08/2015, Rainer Weikusat wrote:
[...]
>> >p_len = strlen(IFACES_PATH);
>> >e_len = strlen(essid);
>> >path = alloca(p_len + e_len + 2);
>> >
>> >strcpy(path, IFACES_PATH);
>> >path[p_len] = '/';
>> >strcpy(path + p_len + 1, essid);
[...]
> You might want to
On Wed, Aug 19, 2015 at 06:19:41PM +0100, Rainer Weikusat wrote:
> Laurent Bercot writes:
>
> [...]
>
> >>int saveFile(char* essid, char* pw) //argv[2], argv[3]
> >>{
> >>char ifilename[1024];
> >>strcpy(ifilename, path_to_interfaces_files);
> >>
> >>
On Wed, Aug 19, 2015 at 01:50:22PM -0400, Steve Litt wrote:
> On Wed, 19 Aug 2015 18:25:45 +0100
> Rainer Weikusat wrote:
>
> > Edward Bartolo writes:
> > > I am not assuming anything and understand the risks of buffer
> > > overflows. The first step I am taking is to make the code function.
> >
On Wed, Aug 19, 2015 at 07:08:25PM +0100, Rainer Weikusat wrote:
> Steve Litt writes:
> > On Wed, 19 Aug 2015 18:25:45 +0100
> > Rainer Weikusat wrote:
> >> Edward Bartolo writes:
> >> > I am not assuming anything and understand the risks of buffer
> >> > overflows. The first step I am taking is
On Wed, Aug 19, 2015 at 06:14:38PM +0100, Edward Bartolo wrote:
...
> As to studying other languages, here, you are NOT talking to a youth
> in his twenties or his teens, but to a 48 year old. Learning a new
> language is a lengthy process and the ones I know are far more than
> enough for what I d
Hi Edward,
On 08/19/2015 03:29 PM, Edward Bartolo wrote:
This is the completed C backend with all functions tested to work. Any
suggestions as to modifications are welcome.
[...]
A word of advice, do not take critizism personal, even if it's harsh,
and especially not if it's coming from people
Am Mittwoch, 19. August 2015 schrieb Edward Bartolo:
> Effectively, you are telling me don't play Russian Roulette with C.
> But I like powerful languages that leave the coder in the wilderness
> without any hand holding, and C is definitely like that. That is why I
> am motivated to use it. The po
Edward,
This grumpy old man who is so old he started coding when BASIC had line
numbers and 8bit Motorola 6800 assembler was state of the art says:-
Don't let others harden the code.
Do it properly from the start.
After many years or using C and C++ my working life is now spent writing
Perl.
S
How to learn C if you don't try it?
You have to code in it to learn the lessons.
Just reading a book about it isn't the same.
On 2015-08-19 20:09, Edward Bartolo wrote:
Effectively, you are telling me don't play Russian Roulette with C.
But I like powerful languages that leave the coder in the
Effectively, you are telling me don't play Russian Roulette with C.
But I like powerful languages that leave the coder in the wilderness
without any hand holding, and C is definitely like that. That is why I
am motivated to use it. The power inherent in C is due to it not
getting in the way of the
Steve Litt writes:
> On Wed, 19 Aug 2015 18:25:45 +0100
> Rainer Weikusat wrote:
>> Edward Bartolo writes:
>> > I am not assuming anything and understand the risks of buffer
>> > overflows. The first step I am taking is to make the code function.
>> > The second step is further debug it until it
On Wed, 19 Aug 2015 18:25:45 +0100
Rainer Weikusat wrote:
> Edward Bartolo writes:
> > I am not assuming anything and understand the risks of buffer
> > overflows. The first step I am taking is to make the code function.
> > The second step is further debug it until it behaves properly and
> > t
Rainer Weikusat writes:
> Edward Bartolo writes:
>> I am not assuming anything and understand the risks of buffer
>> overflows. The first step I am taking is to make the code function.
>> The second step is further debug it until it behaves properly and the
>> third step is to correct any potent
Edward Bartolo writes:
> I am not assuming anything and understand the risks of buffer
> overflows. The first step I am taking is to make the code function.
> The second step is further debug it until it behaves properly and the
> third step is to correct any potential security issues.
Realistica
Edward Bartolo writes:
[...]
> strcpy(text, "auto lo\n");
> fprintf(fp, text);
None of these 2 line pairs is really needed: You can always just use the
literal string directly, eg,
fputs("auto lo\n", fp);
[...]
> char command[1024];
>
Laurent Bercot writes:
[...]
>> int saveFile(char* essid, char* pw) //argv[2], argv[3]
>> {
>> char ifilename[1024];
>> strcpy(ifilename, path_to_interfaces_files);
>>
>> strcat(ifilename, "/");
>> strcat(ifilename, essi
I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and the
third step is to correct any potential security issues. As anyone can
understand, projects, whateve
On Wed, Aug 19, 2015 at 06:46:36PM +0200, Laurent Bercot wrote:
> On 19/08/2015 15:29, Edward Bartolo wrote:
> >This is the completed C backend with all functions tested to work. Any
> >suggestions as to modifications are welcome.
>
> OK, someone has to be the bad guy. Let it be me.
>
> First,
On 19/08/2015 15:29, Edward Bartolo wrote:
This is the completed C backend with all functions tested to work. Any
suggestions as to modifications are welcome.
OK, someone has to be the bad guy. Let it be me.
First, please note that what I'm saying is not meant to discourage you.
I appreciate
Now comes the hardest part for me: preparing a source package and
uploading it. I will need some instructions for that.
Some more debugging and both sources for backend and frontend will be
ready for upload.
--
On 19
On Wed, 19 Aug 2015 14:29:02 +0100
Edward Bartolo wrote:
> This is the completed C backend with all functions tested to work. Any
> suggestions as to modifications are welcome.
>
> The C code:
Hi Edward,
It compiles. Nice!
You get a few warnings:
=
Hi Edward,
On 08/19/2015 03:29 PM, Edward Bartolo wrote:
[...]
The C code:
> [...]
#define opSave 0
#define opSaveConnect 1
#define opQueryConnect 2
#define opDeleteConnect 3
#define opConnectionConnect
This is the completed C backend with all functions tested to work. Any
suggestions as to modifications are welcome.
The C code:
-
#include
#include
#include
#include
#include
//using namespace std;
#define opSave 0
#define opSaveConn
On Tue, Aug 18, 2015 at 02:19:20PM +0200, Didier Kryn wrote:
> Le 18/08/2015 12:49, Edward Bartolo a écrit :
> >At the moment I am stuck trying to use sudo to run ifup from within my
> >frontend.
> Just in case, here are a few things I know about wpa_supplicant:
>
> wpa_supplicant does if
Successfully connected to wifi with the frontend and backend
communicating. But there are still problems regarding text capture.
It will take more tedious debugging time... but in the end, it should
work, hopefully.
> On 18/08/2015, Edward Bartolo wrote:
>> A) I am at the stage of trying to unde
The Progress of My Coding Till Now:
I am attaching two images of the GUI's main window and the only
dialog. The GUI is programmed in Lazarus Pascal.
The backend is in C. The code till now, although it doesn't do anything useful.
--
#include
#include
#
Maybe setting "poStderrToOutPut"
BINGO! That was it. Now it can capture the output even as root.
I had a look at wpa_supplicant.conf and found it is an XML file having
to do with dbus apparently.
For the last five years I have been using ifup manually to connect
whenever I didn't have a network
Edward Bartolo writes:
> Maybe setting "poStderrToOutPut"
>
> BINGO! That was it. Now it can capture the output even as root.
There's a predefined input stream available for capturing output on file
descriptor 2/ stderr
http://www.freepascal.org/docs-html/fcl/process/tprocess.stderr.html
___
If there is a technical reason as to why not to use ifup, please inform me.
On 18/08/2015, Edward Bartolo wrote:
> Maybe setting "poStderrToOutPut"
>
> BINGO! That was it. Now it can capture the output even as root.
>
> I had a look at wpa_supplicant.conf and found it is an XML file having
> to d
Hi Edward,
I've never used Lazarus, origin in the missing Kylix C/C++ for
GNU/Linux, at the same time origin in Borland C/C++and Delphi Pascal for
MS Windows. I usually use QtCreator, and sometimes Anjuta. So, i can't
help you.
Anyway, i think thatfor your purpose the relevance is not in the
Edward Bartolo writes:
> At the moment I am stuck trying to use sudo to run ifup from within my
> frontend. This testing phase is important as I need to ascertain
> myself that the class I am using can actually capture CLI output.
>
> If anyone from Devuan knows of a Lazarus function that I can us
Le 18/08/2015 12:49, Edward Bartolo a écrit :
At the moment I am stuck trying to use sudo to run ifup from within my
frontend.
Just in case, here are a few things I know about wpa_supplicant:
wpa_supplicant does ifups automatically when it connects to a wifi
station. If an interface n
On 08/18/2015 12:49 PM, Edward Bartolo wrote:
At the moment I am stuck trying to use sudo to run ifup from within my
frontend. This testing phase is important as I need to ascertain
myself that the class I am using can actually capture CLI output.
If anyone from Devuan knows of a Lazarus functio
At the moment I am stuck trying to use sudo to run ifup from within my
frontend. This testing phase is important as I need to ascertain
myself that the class I am using can actually capture CLI output.
If anyone from Devuan knows of a Lazarus function that I can use to
capture the output of an ext
Lazarus frontend can now run external programs capturing their textual
output. Hopefully, within a few days, the frontend will be Alpha. :)
On 17/08/2015, Edward Bartolo wrote:
> The Lazarus backend interface unit is as follows but still unfinished:
>
>
>
The Lazarus backend interface unit is as follows but still unfinished:
unit backend;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, stdctrls;
procedure Backend_Save(essid, pw: string);
procedure Backend_Save_Connect(essid, pw: string);
function
James Powell writes:
> While there are packages that can be invisible and unintrusive into
> the system, there are some that cannot.
>
> The problem is responsibility.
>
> Who wants to remain responsible for boot scripts? Upstream or vendor?
>
> Who wants responsibility for providing interoperabil
The classic way to to that is to specify an interface or route metric,
which is a simple integer. As I recall, the interfaces file lets you
specify that, and while the man page does not say whether a higher or
lower number means preferable, on most systems lower means better so
probably it is t
Le 17/08/2015 07:10, Edward Bartolo a écrit :
Forget about the CLI program or daemon. I can create a window with the
following features. Then, we can decide about the backends. We can
avoid having a full fledged sudo setup by ONLY allowing the few
backends to work with it. This should help securi
The backends can be integrated into one single executable not to
clutter the sudoers file and to increase system efficiency.
I propose to place the other interface file in:
/etc/network/interfaces/wifi
I can start the implementation of the GUI (Lazarus Pascal) and the
backend (C++), but I need yo
Forget about the CLI program or daemon. I can create a window with the
following features. Then, we can decide about the backends. We can
avoid having a full fledged sudo setup by ONLY allowing the few
backends to work with it. This should help securitywise.
Propose GUI:
Main window with:
a) list
Hello James,
On 08/17/2015 02:28 AM, James Powell wrote:
While there are packages that can be invisible and unintrusive
> into the system, there are some that cannot.
The problem is responsibility.
Who wants to remain responsible for boot scripts? Upstream or vendor?
Who (developer, vendo
ng back down on you.
Didn't want to get political, philosophical, or religious, but sometimes enough
is enough.
-Jim
From: Franco Lanza<mailto:next...@nexlab.it>
Sent: 8/16/2015 1:46 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re:
Alternatively, instead of running the ifup command with sudo, one can
start the application/daemon itself using sudo. This makes it possible
to use sudo while allowing only our application/daemon to run with
root privileges. I also think, this application can be made into a
daemon and started by a
On Sun, Aug 16, 2015 at 12:13:04PM -0500, T.J. Duchene wrote:
> Well, I suppose the topic has been beat up enough, but I just wanted to clear
> up something before moving on. I want you to understand why I came to the
> Devuan list in the first place. I came here under the assumption that Devuan
On Sun, 16 Aug 2015 18:48:44 +0100
Edward Bartolo wrote:
> I would like to humbly add my little contribution to this thread.
>
> I am posting using Devuan 64 bit connected to a home WIFI without any
> network managers. I connect by using separate /etc/network/interfaces
> files. The one for my h
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
Hi,
wondering what you all have been arguing about :)
The systemd complex is vast and offers many attack vectors.
Just do your thing. :)
Kind regards,
T.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/
I would like to humbly add my little contribution to this thread.
I am posting using Devuan 64 bit connected to a home WIFI without any
network managers. I connect by using separate /etc/network/interfaces
files. The one for my home wifi is in /etc/network/interfaces while
the rest are saved under
Well, I suppose the topic has been beat up enough, but I just wanted to clear
up something before moving on. I want you to understand why I came to the
Devuan list in the first place. I came here under the assumption that Devuan
was going to be a "better Debian" without the shove the Technical C
Le 16/08/2015 08:11, Laurent Bercot a écrit :
On 16/08/2015 06:53, Steve Litt wrote:
The toughest part is how to store the passwords in a way that isn't a
security problem.
Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature
(which is strange, because hostapd supports a wp
Le 16/08/2015 06:27, Steve Litt a écrit :
On Sun, 16 Aug 2015 14:26:41 +1200
Daniel Reurich wrote:
>On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"
> wrote:
> >All that I ever try to say that I think there should be room for
> >both sorts to make Devuan a home. Yes, I think Devuan sh
option, and kill choice. Once systemd is in, it is in.
-Jim
From: T.J. Duchene<mailto:t.j.duch...@gmail.com>
Sent: 8/15/2015 12:48 PM
To: dng@lists.dyne.org<mailto:dng@lists.dyne.org>
Subject: Re: [DNG] Systemd Shims
On Sat, 15 Aug 2015 03:15:50
On 16/08/2015 06:53, Steve Litt wrote:
The toughest part is how to store the passwords in a way that isn't a
security problem.
Unfortunately, /etc/wpa_supplicant.conf doesn't have an include feature
(which is strange, because hostapd supports a wpa_psk_file option).
So you have to store the p
On Sun, 16 Aug 2015 07:37:16 +0300
Lars Noodén wrote:
>
> >> I would be interested in
> >>
> >> * No-dbus replacement for NetworkManager/Wicd
> >>
> >> Are you thinking a C program?
> >
> > HECK no! There's no requirement for this program to be fast, and I
> > want to make it easy on myself. Py
>> I would be interested in
>>
>> * No-dbus replacement for NetworkManager/Wicd
>>
>> Are you thinking a C program?
>
> HECK no! There's no requirement for this program to be fast, and I want
> to make it easy on myself. Python probably, with the minimum Python
> addons, and only addons that ship
On Sun, 16 Aug 2015 14:26:41 +1200
Daniel Reurich wrote:
> On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"
> wrote:
> >All that I ever try to say that I think there should be room for
> >both sorts to make Devuan a home. Yes, I think Devuan should have
> >systemd as an option, but only
On 16 August 2015 7:47:46 AM GMT+12:00, "T.J. Duchene"
wrote:
>On Sat, 15 Aug 2015 03:15:50 -0700
>James Powell wrote:
>
>Hi Jim! =)
>
>>
>> To me, a shim is not the way. Sanitization is what is needed, and if
>> that requires work, then question this, 'Will the work be worth it?'
>> and to m
On Sun, 16 Aug 2015 00:08:11 +0200
shraptor wrote:
> On 2015-08-15 18:01, Steve Litt wrote:
> >>
> >> Please, Steve, provide us with all you mentionned, as an
> >> alternative to mainstream bloated/infected stuff. Since Devuan is
> >> all about freedom, this is the place where to deliver
Fri, 14 Aug 2015 14:49:17 -0700
> Go Linux wrote:
>
>> On Fri, 8/14/15, T.J. Duchene wrote:
>>
>> Subject: Re: [DNG] Systemd Shims
>> To: dng@lists.dyne.org
>> Date: Friday, August 14, 2015, 2:47 PM
>>
>>> I know not everyone here agrees wi
Le 15/08/2015 18:01, Steve Litt a écrit :
On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn wrote:
Le 15/08/2015 02:26, Steve Litt a écrit :
On Fri, 14 Aug 2015 14:49:17 -0700
Go Linux wrote:
On Fri, 8/14/15, T.J. Duchene wrote:
Subject: Re: [DNG] Systemd Shims
To: dng@lists.dyne.org
Simon Hobson writes:
> 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
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
On Sat, 15 Aug 2015 03:15:50 -0700
James Powell wrote:
Hi Jim! =)
>
> To me, a shim is not the way. Sanitization is what is needed, and if
> that requires work, then question this, 'Will the work be worth it?'
> and to me the answer is a definable 'yes'.
I suppose there are some people like yo
On Sat, 15 Aug 2015 12:01:35 -0400
Steve Litt wrote:
Please, Steve, provide us with all you mentionned, as an
> > alternative to mainstream bloated/infected stuff. Since Devuan is
> > all about freedom, this is the place where to deliver to the world.
> > As soon as I can install Devuan on metal
Simon Hobson writes:
> 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
>>
>> ./conf
On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn wrote:
> Le 15/08/2015 02:26, Steve Litt a écrit :
> > On Fri, 14 Aug 2015 14:49:17 -0700
> > Go Linux wrote:
> >
> >> On Fri, 8/14/15, T.J. Duchene wrote:
> >>
> >> Subject: Re: [DNG] Systemd
On Fri, 8/14/15, Steve Litt wrote:
Subject: Re: [DNG] Systemd Shims
To: dng@lists.dyne.org
Date: Friday, August 14, 2015, 7:26 PM
On Fri, 14 Aug 2015 14:49:17 -0700
Go Linux wrote:
> On Fri, 8/14/15, T.J. Duchene wrote:
>
> Subject: Re: [DNG] Systemd Shims
> To: dng@li
1 - 100 of 124 matches
Mail list logo
