Re: [DNG] Download iso 32bit devuan alpha2 or higher(based installation without network)
On 04/02/2016 02:33 PM, Steve Litt wrote: > On Sat, 02 Apr 2016 13:30:05 -0400 > fsmithred wrote: > > >> For those who are more daring or want a minimalist approach, Devuan >> debootstrap is installed, and you can start from scratch and build it >> the way you want. > > Isn't Devuan Debootstrap a chroot install, kinda like Arch or Gentoo > (minus all the compilation)? > > SteveT > Yes, it's a chroot install with no compilation. Just apt-get whatever. You get to do fun stuff like try to boot into the new system when you forgot to install a bootloader or log in when you forgot to create a root password. -fsr ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd installed and running in default desktop
On April 1, 2016 8:09:10 AM CDT, Boruch Baum ::> Are you sure that output is correct? ::No, it was me. I manually added a paste from my dpkg -l output. Ah, OK. :: ::Are you running the default devuan desktop, xfce? I was , but then switched to lxde as the drop-down terminal in xfce would segault sometimes. -- Sent from a Mobile device.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Download iso 32bit devuan alpha2 or higher(based installation without network)
On Sat, 02 Apr 2016 13:30:05 -0400 fsmithred wrote: > For those who are more daring or want a minimalist approach, Devuan > debootstrap is installed, and you can start from scratch and build it > the way you want. Isn't Devuan Debootstrap a chroot install, kinda like Arch or Gentoo (minus all the compilation)? SteveT Steve Litt March 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Sat, 2 Apr 2016 10:55:53 +0100
KatolaZ wrote:
> On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote:
>
> [cut]
>
> >
> >
> > =
> > char * read_bbs(){
> > char rtrn[WAY_BIGGER_THAN_EVER_NEEDED];
> > strcpy(rtrn, grab_bbs_part1());
> > strcat(rtrn, grab_bbs_part2());
> > return(rtrn);
> > }
> >
> > result_string = read_bbs();
> > do_other_stuff();
> > use_result_string(result_string);
> > =
[snip]
>
> Well, that one is a completely different beast...
Yes it is, isn't it? :-)
> You never return a
> pointer to an automatic variable,
How'd you learn that? I learned that by this particular incident, and I
*NEVER* did that again.
> unless it has been declared
> "static",
Yes. My "solution" was to prepend the variable declaration with the
word "static", and it never crashed again.
> for the simple reason that the variable does not exist any
> more when the function returns. Your code probably "worked" only
> because there was no call to any other functions in between (and thus
> the stack was magically unmodified), but otherwise that code should in
> general blow up pretty early, whatever the size of
> WAY_BIGGER_THAN_EVER_NEEDED...
It was a long time ago, and I don't have the code anymore, but I think
what happened was that in the function returning the automatic char*, I
had declared a lot of big automatic variables before the string I
returned, such that subsequent functions never declared enough to reach
that area of the stack, so although it was out of scope, it was left
alone.
However, once in a while a raly long piece of input data came
through, which used up so much stack on later subroutines that the
stack corresponded to the returned local pointer was overwritten, and
more, and then bang, the program terminated.
> Actually, returning a pointer to a local (automatic) static array is
> exactly what some implementations of standard functions like "strtok"
> do, and it works perfectly if you don't have multiple threads using
> the same function. But you should know exactly what you are doing...
Yeah, I do that alot, but I document the daylights out of the fact that
if you use it twice, you need to copy away the first return.
SteveT
Steve Litt
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Download iso 32bit devuan alpha2 or higher(based installation without network)
On 04/01/2016 09:45 AM, Ismael L. Donis Garcia wrote: > Thanks Reiterated > I try refracta in the absence of a devuan iso. > I can not do more because my knowledge of linux are very little, I can > only constribuir recommending this project and reporting about it. > > | ISMAEL | > > I just uploaded new Refracta isos this morning. refracta8_xfce i386 and amd64 beta. Both are built on Devuan. The older isos contained some packages from deb-multimedia, but those have been removed in the new isos. They're at the top of the list here - https://sourceforge.net/projects/refracta/files/testing/ Make a live CD or USB with the iso. If you need help with that, just ask. Run Refracta Installer from the menu, and it will install everything that's on the live CD/USB. No network is needed for the installation. The selection of packages is a little different from what you get with the official Devuan alpha releases, but it's still xfce, and it only uses Devuan repositories. For those who are more daring or want a minimalist approach, Devuan debootstrap is installed, and you can start from scratch and build it the way you want. fsmithred ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] xscreensaver issues (including hardcoded DEBIAN!)
Adam Borowski writes:
> On Fri, Apr 01, 2016 at 12:58:23PM -0400, Boruch Baum wrote:
>> Just looking at issues with the devuan default desktop's screensave, and
>> its config file: ~/.xscreensaver file, posted here for the attention of
>> the maintainers and the interest of members of the list.
>>
>> 1] Obnoxious nag messages - All logins to the devuan default desktop
>> begin with not one but two separate nag messages from xscreensaver. The
>> first "warns" the user that the version is out of date. The second
>> "warns" the user that the sysadmin is doing a dis-service by keeping it
>> out of date.
>>
>> 2] forced config screen - after the two obnoxious nag messages, one is
>> forced to be confronted with the xscreensaver customization screen
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
Oh wow. It's incredible to which degree people go out of their way just
to be obnoxious. Below is a patch removing every trace of this
nonsense.
---
diff -pru xscreensaver-5.30/driver/demo-Gtk.c
xscreensaver-5.30.p/driver/demo-Gtk.c
--- xscreensaver-5.30/driver/demo-Gtk.c 2014-06-04 10:30:47.0 +0100
+++ xscreensaver-5.30.p/driver/demo-Gtk.c 2016-04-02 17:25:16.550205544
+0100
@@ -5291,21 +5291,6 @@ main (int argc, char **argv)
if (! s->debug_p)
the_network_is_not_the_computer (s);
-
- if (senescent_p())
-warning_dialog (s->toplevel_widget,
- _("Warning:\n\n"
-"This version of xscreensaver is VERY OLD!\n"
-"Please upgrade!\n"
-"\n"
-"http://www.jwz.org/xscreensaver/\n";
-"\n"
-"(If this is the latest version that your distro ships, then\n"
-"your distro is doing you a disservice. Build from source.)\n"
-),
- D_NONE, 7);
-
-
/* Run the Gtk event loop, and not the Xt event loop. This means that
if there were Xt timers or fds registered, they would never get serviced,
and if there were any Xt widgets, they would never have events delivered.
diff -pru xscreensaver-5.30/driver/lock.c xscreensaver-5.30.p/driver/lock.c
--- xscreensaver-5.30/driver/lock.c 2014-08-05 07:21:30.0 +0100
+++ xscreensaver-5.30.p/driver/lock.c 2016-04-02 17:23:46.966177910 +0100
@@ -487,11 +487,6 @@ make_passwd_window (saver_info *si,
* room for the dialog to grow without going off the edge of the screen. */
max_string_width_px *= 0.75;
- if (!info_msg && senescent_p())
-info_msg = ("\n"
-"This version of XScreenSaver\n"
-"is very old! Please upgrade!\n");
-
pw->info_label = mlstring_new(info_msg ? info_msg : pw->body_label,
pw->label_font, max_string_width_px);
diff -pru xscreensaver-5.30/driver/prefs.c xscreensaver-5.30.p/driver/prefs.c
--- xscreensaver-5.30/driver/prefs.c2014-08-08 18:57:20.0 +0100
+++ xscreensaver-5.30.p/driver/prefs.c 2016-04-02 17:22:59.056302780 +0100
@@ -1658,83 +1658,3 @@ stop_the_insanity (saver_preferences *p)
if (p->auth_warning_slack < 0) p->auth_warning_slack = 0;
if (p->auth_warning_slack > 300) p->auth_warning_slack = 300;
}
-
-
-Bool
-senescent_p (void)
-{
- /* If you are in here because you're planning on disabling this warning
- before redistributing my software, please don't.
-
- I sincerely request that you do one of the following:
-
- 1: leave this code intact and this warning in place, -OR-
-
- 2: Remove xscreensaver from your distribution.
-
- I would seriously prefer that you not distribute my software at all
- than that you distribute one version and then never update it for
- years.
-
- I am *constantly* getting email from users reporting bugs that have
- been fixed for literally years who have no idea that the software
- they are running is years out of date. Yes, it would be great if we
- lived in the ideal world where people checked that they were running
- the latest release before they report a bug, but we don't. To most
- people, "running the latest release" is synonymous with "running the
- latest release that my distro packages for me."
-
- When they even bother to tell me what version they're running, I
- say, "That version is three years old!", and they say "But this is
- the latest version my distro ships". Then I say, "your distro
- sucks", and they say "but I don't know how to compile from source,
- herp derp I eat paste", and *everybody* goes away unhappy.
-
- It wastes an enormous amount of my time, and kind of makes me regret
- ever having released this software in the first place.
-
- So seriously. I ask that if you're planning on disabling this
- obsolescence warning, that you instead just remove xscreensaver from
- your distro entirely. Everybody will be happier that way. Check
- out gnome-screensaver instead, I understand it's really nice.
-
- Of course, my license allows you to ignore me and do whatever the
- fuck
Re: [DNG] Making sense of C pointer syntax.
aitor_czr writes:
> On 03/31/16 16:07, KatolaZ wrote:
>> On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote:
>>
>> [cut]
>>
> >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat <
> >rainerweiku...@virginmedia.com> wrote:
> >
> >There's one
> > >>important difference:
> > >>
> > >>char chars[] = "12345";
> > >>
> > >>cause the compiler to reserve six bytes (five chars + terminating 0)
> > >>in
> > >>some location the program can write to. Afterwards,
> > >>
> > >>*chars = R;
> > >>
> > >>could be used to change the string to R2345.
>>> >
>>> >This is because
>>> >
>>> >*chars <---> *(chars+0) <---> chars[0]
>>> >
>>> >are analogous. So, chars[0] changes from 1 to R.
>>> >
>> Again. being pedantic here the assignment:
>>
>>*chars = R;
>>
>> assigns the value of the variable R (which should be a char) to the
>> first byte of the memory area pointed by chars.
Considering what it was supposed to mean, it should have been obvious
that I forgot the quotes. Had R been a variable, its type could have
been any numerical type as the value is to be converted as required (in
fact, the type of 'R' is int, not char).
Some people think this is a useful convenience feature. Others are
convinced that that's a sign of tthe devil's agents being secretly at work to
deprave mankind and an eternity of purgatory among dysfunctional
computer must invariably ... hold a sec ... that already
happened. Despite the "other's opinion" is generally accepted. Hmm ...
#include
char chars[] = "12345";
int main(void)
{
double R = 82.34;
0[chars] = R;
puts(chars);
return 0;
}
Turned into a program which can be compiled to avoid accidental syntax
errors this time.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Sat, Apr 02, 2016 at 10:55:53AM +0100, KatolaZ wrote:
> On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote:
>
> [cut]
>
> >
> >
> > =
> > char * read_bbs(){
> > char rtrn[WAY_BIGGER_THAN_EVER_NEEDED];
> > strcpy(rtrn, grab_bbs_part1());
> > strcat(rtrn, grab_bbs_part2());
> > return(rtrn);
> > }
> >
> > result_string = read_bbs();
> > do_other_stuff();
> > use_result_string(result_string);
> > =
> >
> > Well, it worked 99.6% of the time, but once in a while the whole
> > program blew up. :-). I solved this intermittent on my third visit,
> > racked up probably 10 hours trying to fix it, and my problem probably
> > cost a couple hundred hours of keypuncher time before I fixed it.
> >
> > WAY_BIGGER_THAN_EVER_NEEDED really was way bigger than ever needed. Bad
> > programming, but that wasn't the problem.
> >
> > All I can say is I *never* made that mistake again.
> >
>
> Well, that one is a completely different beast... You never return a
> pointer to an automatic variable, unless it has been declared
> "static", for the simple reason that the variable does not exist any
> more when the function returns. Your code probably "worked" only
> because there was no call to any other functions in between (and thus
> the stack was magically unmodified), but otherwise that code should in
> general blow up pretty early, whatever the size of
> WAY_BIGGER_THAN_EVER_NEEDED...
The bigger WAY_BIGGER... is the lss often it would be likely to fail.
If the stack grows in the directio of lower memory addresses, the
beginning of rtrn would be farther from the caller's stack position,
and thus less likely to be overrun by other function calls.
But it's still wrong.
-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Making sense of C pointer syntax.
On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote:
[cut]
>
>
> =
> char * read_bbs(){
> char rtrn[WAY_BIGGER_THAN_EVER_NEEDED];
> strcpy(rtrn, grab_bbs_part1());
> strcat(rtrn, grab_bbs_part2());
> return(rtrn);
> }
>
> result_string = read_bbs();
> do_other_stuff();
> use_result_string(result_string);
> =
>
> Well, it worked 99.6% of the time, but once in a while the whole
> program blew up. :-). I solved this intermittent on my third visit,
> racked up probably 10 hours trying to fix it, and my problem probably
> cost a couple hundred hours of keypuncher time before I fixed it.
>
> WAY_BIGGER_THAN_EVER_NEEDED really was way bigger than ever needed. Bad
> programming, but that wasn't the problem.
>
> All I can say is I *never* made that mistake again.
>
Well, that one is a completely different beast... You never return a
pointer to an automatic variable, unless it has been declared
"static", for the simple reason that the variable does not exist any
more when the function returns. Your code probably "worked" only
because there was no call to any other functions in between (and thus
the stack was magically unmodified), but otherwise that code should in
general blow up pretty early, whatever the size of
WAY_BIGGER_THAN_EVER_NEEDED...
Actually, returning a pointer to a local (automatic) static array is
exactly what some implementations of standard functions like "strtok"
do, and it works perfectly if you don't have multiple threads using
the same function. But you should know exactly what you are doing...
My2Cents
KatolaZ
--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
