Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 01:57 AM, KatolaZ wrote: So the problem is not the language. While I cited Perl and Python in particular, the gist of my rant was about sloppy coding practices. I singled a few things out because I personally feel that their communities can be regarded as some of the worst offenders in that regard. Others disagree, and that's just fine. We aren't going to change things by talking about it, so this is mainly an academic exercise. The truth is that in the last 30 years we have started doing millions new things with computers, and these new needs have unavoidably brought new software and new libraries. Despite I like to keep my programs small, simple and reliable, I believe that it is not possible to set limits to the creativity of coders: let them use all the freedom they need. The freedom you describe has always been present. It was here long before I ever showed up and will be here long after I am not. I just don't think that sloppy, shoddy work should be classified as anything other than what it is, and not described as "freedom." Again, that's just an opinion. I'm old school. Unless they use this freedom to break my toys apart, in which case I get nervous ;) I personally don't see the massive usage of Perl or Python *per se* as a threat to the reliability of the OS. Danger to the OS, no, not in a strict sense - because the portions of the OS we would be concerned about are not written in them. I was referring to code that is used far more often: user applications - which deals with the majority of time spent. The number of interpreted user applications are a performance concern, and the poor design practices that the languages actually force on or encourage neophyte and more advanced programmers to use is a concern. I think that bad programming habits in C or C++ are even more dangerous than good Perlisms, as the SSH heartbleed saga has recently shown. I'd shoot that argument down almost immediately. What you are actually contrasting is poor maintenance of a codebase, not what language that was used. Contrary to what most "modern" programmers would like to promote, I do not believe for one second that mandatorily garbage collected, bounded languages create better code design. I would subscribe to precisely the reverse, actually. If there is a flaw in the collector or the bound check, you have an extremely hard to fix problem that affects virtually everything. You are also continuously wasting resources on overhead for features that can fail without warning. Even if you set that aside, the reality is that you are investing in all of that wasted overhead for vanishing returns. At no time are those features a 100% effective solution to the problems they were intended to solve, and they create entirely new ones. So what good are they, really? Any code that does not work reliably isn't worth much. I'd much rather do everything manually. At least, I know that it is done correctly, and I can perform the appropriate testing to prove it. In my opinion, that is why C will probably never be replaced in my lifetime. There are differing views on this, naturally. I can only speak from my own experience and say that every single "modern" language I have used has been a PITA, without exception. t.j. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 02:59:40AM -0600, T.J. Duchene wrote: [cut] > > Contrary to what most "modern" programmers would like to promote, I > do not believe for one second that mandatorily garbage collected, > bounded languages create better code design. I would subscribe to > precisely the reverse, actually. If there is a flaw in the > collector or the bound check, you have an extremely hard to fix > problem that affects virtually everything. You are also > continuously wasting resources on overhead for features that can > fail without warning. Even if you set that aside, the reality is > that you are investing in all of that wasted overhead for vanishing > returns. At no time are those features a 100% effective solution to > the problems they were intended to solve, and they create entirely > new ones. So what good are they, really? > > Any code that does not work reliably isn't worth much. > I honestly can't see all this failing around of code written in Python, Perl or Ruby :) Bad code is bad code in C, C++, Perl, Python, LISP, or whatever other language you can think of, and bad code will either get better or die. IMHO the evil is not in any specific language, but in the way you use it. Concerning "performance", well it is not always the most important thing. I personally use C a lot for simulations and scientific calculations, but I would never do data analysis and postprocessing in C, since it would require every time a few days just to have a running thing to be used only once or twice, while I can do the same task in Python with 10 minutes coding and a few minutes more processing. In that case, *my* time and *my* performance is more important than the time it takes to the machine to crunch a few million numbers :) While I totally agree about the necessity to teach "good programming practices" to young coders, I am convinced that there is no such thing as the "perfect" language. It's just a matter of taste. And if you are a good coder you will write good code in asm, C, Perl, Python or Erlang. If you are not, then your code will be crap anyway :) HND 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
Re: [Dng] Devuan Weekly News XI
В Sun, 1 Mar 2015 21:19:04 + Isaac Dunham пишет: > Over here, those who are more particular about such things consider > "ass" to be a somewhat vulgar term when referring to the posterior > rather than a male donkey (and "kick ass" refers to the aforesaid > pportion of the anatomy). Not quite a swear word, but something to > be avoided. Big thanks for explanation, Isaac! A simple suggestion of mine - i even could not suppose, that it will make such noise. I though all will make their on conclusions and will go farther, hopefully w/o the wording. Sthu. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Circumvention Tech Festival
В Sun, 1 Mar 2015 14:37:55 -0430 Richard пишет: > > Can Devuan be a security-aware, privacy-aware distro? > > > > Er Envite > > It may be. > Time will tell. > No one knows yet. Security should be kept in mind always - otherwise who will use it? - Just for offline machines - i guess it scarcely be found today. Sthu. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
> > Contrary to what most "modern" programmers would like to promote, I > > do not believe for one second that mandatorily garbage collected, > > bounded languages create better code design. > > I honestly can't see all this failing around of code written in > Python, Perl or Ruby :) garbage collection is actually a compounding issue, meaning that while it may not be a problem for programs that are only active for a few minutes before terminating, it is a problem for programs that are high intensity or run indefinitely. it's typical (just ask an admin) for internally developed server side Java business database applications to require they be restarted daily because the devs cant figure out why they are "running out" of memory and it's easier just to have it restarted. if they were developing in perl, python or any other number of GC languages, it would still be an issue. while it /can/ be used properly, garbage collection is more of a hassle than it's worth. --Gravis On Mon, Mar 2, 2015 at 4:26 AM, KatolaZ wrote: > On Mon, Mar 02, 2015 at 02:59:40AM -0600, T.J. Duchene wrote: > > [cut] > >> >> Contrary to what most "modern" programmers would like to promote, I >> do not believe for one second that mandatorily garbage collected, >> bounded languages create better code design. I would subscribe to >> precisely the reverse, actually. If there is a flaw in the >> collector or the bound check, you have an extremely hard to fix >> problem that affects virtually everything. You are also >> continuously wasting resources on overhead for features that can >> fail without warning. Even if you set that aside, the reality is >> that you are investing in all of that wasted overhead for vanishing >> returns. At no time are those features a 100% effective solution to >> the problems they were intended to solve, and they create entirely >> new ones. So what good are they, really? >> >> Any code that does not work reliably isn't worth much. >> > > I honestly can't see all this failing around of code written in > Python, Perl or Ruby :) Bad code is bad code in C, C++, Perl, Python, > LISP, or whatever other language you can think of, and bad code will > either get better or die. IMHO the evil is not in any specific > language, but in the way you use it. > > Concerning "performance", well it is not always the most important > thing. I personally use C a lot for simulations and scientific > calculations, but I would never do data analysis and postprocessing in > C, since it would require every time a few days just to have a running > thing to be used only once or twice, while I can do the same task in > Python with 10 minutes coding and a few minutes more processing. In > that case, *my* time and *my* performance is more important than the > time it takes to the machine to crunch a few million numbers :) > > While I totally agree about the necessity to teach "good programming > practices" to young coders, I am convinced that there is no such thing > as the "perfect" language. It's just a matter of taste. And if you are > a good coder you will write good code in asm, C, Perl, Python or > Erlang. If you are not, then your code will be crap anyway :) > > HND > > 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
I've been playing with golang recently and although you can't strictly stop it garbage collecting you can compile with a flag which produces the output of the escape analysis. Anything that doesn't escape gets stored on the stack. Things that might are stored in the heap. I often compile with the flag and see if there is a way to use the stack rather than the heap in what I am doing. In hope that the heap will get hit less. Perhaps the other gc languages have a similar feature that isn't being used as much as it might? Matthew Melton m...@mjmworks.co.uk Gravis wrote >> > Contrary to what most "modern" programmers would like to promote, I >> > do not believe for one second that mandatorily garbage collected, >> > bounded languages create better code design. >> >> I honestly can't see all this failing around of code written in >> Python, Perl or Ruby :) > >garbage collection is actually a compounding issue, meaning that while >it may not be a problem for programs that are only active for a few >minutes before terminating, it is a problem for programs that are high >intensity or run indefinitely. it's typical (just ask an admin) for >internally developed server side Java business database applications >to require they be restarted daily because the devs cant figure out >why they are "running out" of memory and it's easier just to have it >restarted. if they were developing in perl, python or any other >number of GC languages, it would still be an issue. while it /can/ be >used properly, garbage collection is more of a hassle than it's worth. >--Gravis > > >On Mon, Mar 2, 2015 at 4:26 AM, KatolaZ wrote: >> On Mon, Mar 02, 2015 at 02:59:40AM -0600, T.J. Duchene wrote: >> >> [cut] >> >>> >>> Contrary to what most "modern" programmers would like to promote, I >>> do not believe for one second that mandatorily garbage collected, >>> bounded languages create better code design. I would subscribe to >>> precisely the reverse, actually. If there is a flaw in the >>> collector or the bound check, you have an extremely hard to fix >>> problem that affects virtually everything. You are also >>> continuously wasting resources on overhead for features that can >>> fail without warning. Even if you set that aside, the reality is >>> that you are investing in all of that wasted overhead for vanishing >>> returns. At no time are those features a 100% effective solution to >>> the problems they were intended to solve, and they create entirely >>> new ones. So what good are they, really? >>> >>> Any code that does not work reliably isn't worth much. >>> >> >> I honestly can't see all this failing around of code written in >> Python, Perl or Ruby :) Bad code is bad code in C, C++, Perl, Python, >> LISP, or whatever other language you can think of, and bad code will >> either get better or die. IMHO the evil is not in any specific >> language, but in the way you use it. >> >> Concerning "performance", well it is not always the most important >> thing. I personally use C a lot for simulations and scientific >> calculations, but I would never do data analysis and postprocessing in >> C, since it would require every time a few days just to have a running >> thing to be used only once or twice, while I can do the same task in >> Python with 10 minutes coding and a few minutes more processing. In >> that case, *my* time and *my* performance is more important than the >> time it takes to the machine to crunch a few million numbers :) >> >> While I totally agree about the necessity to teach "good programming >> practices" to young coders, I am convinced that there is no such thing >> as the "perfect" language. It's just a matter of taste. And if you are >> a good coder you will write good code in asm, C, Perl, Python or >> Erlang. If you are not, then your code will be crap anyway :) >> >> HND >> >> 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 >___ >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] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 07:01:24AM -0500, Gravis wrote: [cut] > > garbage collection is actually a compounding issue, meaning that while > it may not be a problem for programs that are only active for a few > minutes before terminating, it is a problem for programs that are high > intensity or run indefinitely. it's typical (just ask an admin) for > internally developed server side Java business database applications > to require they be restarted daily because the devs cant figure out > why they are "running out" of memory and it's easier just to have it > restarted. if they were developing in perl, python or any other > number of GC languages, it would still be an issue. while it /can/ be > used properly, garbage collection is more of a hassle than it's worth. Hi Gravis, I appreciate that, but I personally can't see how the problems of garbage collection in Java are related with good or bad programming practices, or with a supposedly terribly long chain of dependencies required by Perl and Python modules somebody mourned about earlier in the thread :) And I don't get how this relates to the development of Devuan, after all... Best 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
Re: [Dng] No way to use a prepartioned disk?
On Mar 1, 2015 6:26 PM, "fsmithred" wrote: > > > > > On 03/01/2015 04:41 PM, Hendrik Boom wrote:> On Sun, Mar 01, 2015 at 05:44:47PM +, Hendrik Boom wrote: > >>> I tried using the valentine installer on a disk that already had three > >>> primary partitions and a lot of empty space. > >> > >> In case it's relevant, I was using the expert install, wanting to make > >> my own paritioning decisions. That's what I usually do when installing > >> Debian. Was this a mistake? > >> > >> -- hendrik > >> > > > > The first time I installed the valentine preview, it was on existing > partitions in a virtualbox VM. I chose a regular (non-expert)install, > chose manual partitioning. > > When the partitioner showed me the existing partitions, I noticed that > there were two partitions instead of one. There was a swap partition > inside an extended partition, which I'm sure I did not create. Other than > that, the installation went fine. > > I then booted the VM with a live CD and repartitioned the drive using > gparted. Made a single partition again, then rebooted the valentine iso to > see if the same thing would happen, but it did not. I could not reproduce > it. I even tried a third time. > > Except for that first install, the partitioner did what I expected it to > do - it showed me the existing partitions and allowed me to choose whether > to use them or not. > > fsr > > >> > >> I could not get manual partitioning to leave the existing partitions > >> alone and install devuan to secondary partitions in the empty space. The > >> closest I could get was a question whether I'd like it to replace the > >> existing partition table with a new empty one. Of course I answered > >> 'no'. I wanted it to start from the existing partition structure. > >> 'yes' seemed somewhat dangerous. > >> > >> Well, in reality, those partitions wera a copy of files I had elsewhere > >> and wanted to be able to use on the new system in a dual-boot > >> configuration, so in theory I could have gone further and restored those > >> partition later, and when I have time I may still do that to further test > >> the installer. But I'd rather test how well int cooperates with other > >> existing systems. > >> > >> -- hendrik > >> > >> ___ > >> 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 mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Installing Valentine on HD on AA1: 1. First three attempts failed. 1st with the GUI and then with the curses version. Each picked up and connected to wifi. 2. All stopped at 33% of formatting the chosen partition. I waited at least 15 minutes for each. 3. Formatted the desired partition with gparted then ran the curses installer without doing any partitioning. Valentine is happily installing at the moment. 4. I'll give it a bit more use this time. Previously just wanted to see the shape of things to come. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, 2 Mar 2015, T.J. Duchene wrote: On 03/01/2015 05:56 PM, Tor Myklebust wrote: The perl-base package pre-depends on libc6 and dpkg. And nothing else. I was not referring to all the software that depends on them when using Debian/Devuan. I've never believed that they make good choice for a required component. Frankly, I've also believe that interpreted languages should never be used for anything other than a teaching tool. If you must use something like that, at least use something that supports JIT to native code. I'm even more confused by your position than I was before. The things that depend on perl-base that you'd want in any minimal system are adduser, linux-base (indirectly via libuuid-perl), and debconf. adduser depends on perl-base because adduser and friends are perl scripts. linux-base depends on perl-base because /usr/bin/linux-version is a perl script. debconf depends on perl-base because debconf is implemented as a collection of perl scripts and perl modules. I do not see why anybody would insist that something like adduser is written in either a compiled language or a language with an effective just-in-time compiler available. Very little time is spent running adduser on any system I am aware of. The same goes for linux-version. You can write programs in Perl or Python that do not depend on any modules that are not installed in the base Perl and Python packages. I never suggested otherwise. In fact, I went out of my way to say that the community attitude of overuse and the extensions specifically were the problem, not the core. What "community attitude of overuse"? There is a long tail of available perl modules and quality tends to taper off as you get to lesser-used libraries. This is true of libraries in every language I am aware of. c) In both languages, modules are usually something of a "black art" and notorious for being unreliable at unexpected times. Are you claiming that perl's module system does not always work as expected? Or just that some perl modules are poorly-written? My remarks about Perl stem from poor QA in many Perl modules, and issues with the community/CPAN. Why pick on perl? Why not pick on the huge number of low-quality C libraries that are out there? You gave MailScanner as a concrete example of a perl package that pulls in, in your view, too many dependencies. But consider what MailScanner does; it integrates MTAs with several different pieces of filtering software and does some of its own scanning as well. (I suppose you could argue that its scope is too broad, but you weren't arguing that.) That means it has to be able to parse emails (some of which are HTML), extract attachments, uncompress archives, and ask some external programs what they think about various things. If you're writing software like this, it makes perfect sense to rely on someone else's code for handling mail, MIME, HTML, compressed archives, and so forth---you won't get it right yourself and you don't want to spend your time maintaining those components when you could be making your package better at its core task. In my experience, while you can generally expect things like the Perl core language to act reliably,you can't expect the same of the rest of the Perl ecosystem to do the same. The QA simply is not there. Not to mention that all of this can massively impact performance. This reads like FUD to me. Yes, it's possible to write Perl modules. Like anything else, it's possible to do slipshod work. Why are you trying to paint this as a *bad* thing? Just because my opinions may not be conventional, does not mean that I am "painting" anything. Convention does not have much to do with it. You tried to attribute a perceived lack of software quality in perl libraries to perl itself, or to perl's ecosystem, or to the fact that perl is interpreted. (I'm still not sure which one you're claiming.) It is straightforward to write low-quality software in every language I have heard of, interpreted or not, so the problem is clearly not with perl, or with perl developers as a community, or with interpreting code as a concept. Personally, I think you missed the crux of what I was trying to say about the piling one layer of interpreted software, one abstraction, on top of another. I don't think you said what you were trying to say. Judicious use of abstraction is what lets us write useful software in the first place. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] No way to use a prepartioned disk?
On Mar 2, 2015 10:41 AM, "Richard" wrote: > > > On Mar 1, 2015 6:26 PM, "fsmithred" wrote: > > > > > > > > On 03/01/2015 04:41 PM, Hendrik Boom wrote:> On Sun, Mar 01, 2015 at 05:44:47PM +, Hendrik Boom wrote: > > >>> I tried using the valentine installer on a disk that already had three > > >>> primary partitions and a lot of empty space. > > >> > > >> In case it's relevant, I was using the expert install, wanting to make > > >> my own paritioning decisions. That's what I usually do when installing > > >> Debian. Was this a mistake? > > >> > > >> -- hendrik > > >> > > > > > > > > The first time I installed the valentine preview, it was on existing > > partitions in a virtualbox VM. I chose a regular (non-expert)install, > > chose manual partitioning. > > > > When the partitioner showed me the existing partitions, I noticed that > > there were two partitions instead of one. There was a swap partition > > inside an extended partition, which I'm sure I did not create. Other than > > that, the installation went fine. > > > > I then booted the VM with a live CD and repartitioned the drive using > > gparted. Made a single partition again, then rebooted the valentine iso to > > see if the same thing would happen, but it did not. I could not reproduce > > it. I even tried a third time. > > > > Except for that first install, the partitioner did what I expected it to > > do - it showed me the existing partitions and allowed me to choose whether > > to use them or not. > > > > fsr > > > > >> > > >> I could not get manual partitioning to leave the existing partitions > > >> alone and install devuan to secondary partitions in the empty space. The > > >> closest I could get was a question whether I'd like it to replace the > > >> existing partition table with a new empty one. Of course I answered > > >> 'no'. I wanted it to start from the existing partition structure. > > >> 'yes' seemed somewhat dangerous. > > >> > > >> Well, in reality, those partitions wera a copy of files I had elsewhere > > >> and wanted to be able to use on the new system in a dual-boot > > >> configuration, so in theory I could have gone further and restored those > > >> partition later, and when I have time I may still do that to further test > > >> the installer. But I'd rather test how well int cooperates with other > > >> existing systems. > > >> > > >> -- hendrik > > >> > > >> ___ > > >> 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 mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > Installing Valentine on HD on AA1: > 1. First three attempts failed. 1st with the GUI and then with the curses version. > Each picked up and connected to wifi. > 2. All stopped at 33% of formatting the chosen partition. I waited at least 15 minutes for each. > 3. Formatted the desired partition with gparted then ran the curses installer without doing any partitioning. Valentine is happily installing at the moment. > 4. I'll give it a bit more use this time. Previously just wanted to see the shape of things to come. Note: Installed to MBR of HD. Only needs reinstall grub2 to return to previous setup. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 12:16:52AM -0600, T.J. Duchene wrote: > > On 03/01/2015 05:56 PM, Tor Myklebust wrote: > > > >The perl-base package pre-depends on libc6 and dpkg. And nothing else. > I was not referring to all the software that depends on them when > using Debian/Devuan. I've never believed that they make good choice > for a required component. Even more heavily used in Deban is the shell. Would you care to advise its abolition? > Frankly, I've also believe that > interpreted languages should never be used for anything other than a > teaching tool. There's one huge advantage of interpreted languages: The code you see in the editor *is* the code you are running. No compiler to leave an obsolete executable around that you might be executing instead. This is a security issue. >If you must use something like that, at least use > something that supports JIT to native code. I view JIT as a form of interpretation. That's a question of CPU efficency, which in a lot of cases (some mentioned in this thread) does not matter. When it comes to code that's run often, I prefer statically typed languages. A lot of bugs are caught by the compiler, many of them bugs that evade the test suite. It's possible to have a statically-typed intepreter, but such things are scarce. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
Le 02/03/2015 16:40, Hendrik Boom a écrit : >Frankly, I've also believe that >interpreted languages should never be used for anything other than a >teaching tool. There's one huge advantage of interpreted languages: The code you see in the editor*is* the code you are running. No compiler to leave an obsolete executable around that you might be executing instead. I consider weakly typed, or even non-typed languages should *never* be used for teaching. Unless one intends to teach loose programming. Yet I agree interpreted languages are convenient for small things, precisely because they are interpreted. Conveniency also include fast development and architecture-independant packaging. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 05:35:42PM +0100, Didier Kryn wrote: > > Le 02/03/2015 16:40, Hendrik Boom a écrit : > >>>Frankly, I've also believe that > >>>interpreted languages should never be used for anything other than a > >>>teaching tool. > >There's one huge advantage of interpreted languages: The code you see in > >the editor*is* the code you are running. No compiler to leave an > >obsolete executable around that you might be executing instead. > > I consider weakly typed, or even non-typed languages should > *never* be used for teaching. Unless one intends to teach loose > programming. > This adds even more confusion to the discussion, as Python (one of the blamed ones) actually *IS* a strongly-typed language. You might see *dynamic* typing as a potential issue, and we could even agree on that to some extent, but that's another story. Please let's try to be fair and stick to the facts, otherwise the discussion is not useful... > Yet I agree interpreted languages are convenient for small > things, precisely because they are interpreted. Conveniency also > include fast development and architecture-independant packaging. > And as they have already explained above, this is exactly the reason why some non-critical Debian system utilities (such as debconf or adduser) are written in Perl or Python :) And they were so cool to manage to reduce the dependencies of these packages to the bare minimum (basically, the interpreter). I would like to point out that this is not just a curse of Debian. Also other distros and other operating systems (like FreeBSD) use perl and python scripts for some non-critical system software, just because sometimes you can do in three lines of Perl what would require a few hundred lines of C (plus a few additional libraries)... 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
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, 02 Mar 2015 00:16:52 -0600 "T.J. Duchene" wrote: > Frankly, I've also believe that > interpreted languages should never be used for anything other than a > teaching tool. If you must use something like that, at least use > something that supports JIT to native code. If I were the king of all open source, and a programmer asked to write a program in C, I would ask them to justify that. Will their performance bottleneck be the code itself rather than the typist's fingers? Will the time taken by their program materially affect the overall performance of the computer? Do they need special access to the metal that Python doesn't give them? Do they need to deal with a library not accessible via Python, or even Lua? Because here's the thing. We all say we're great programmers, but somehow, on lots of software, buffers get overrun. Pointers go errant. Programs proceed after failed mallocs. Malloc/free loops somehow start to accumulate more allocation than freeing. None of this is an issue in Python. In Python, programmer mistakes tend to affect the data, not the system. Python long ago solved the vast majority of security problems: It's secure, and when it's not, because of its millions of users, you find out fast. Yes, I know that Python's got that 2.x vs 3.x problem. Yes, I know that a lot of people hate Python's significant whitespace. Yes, I know that a Python import is a dependency, just as sure as libarbitraryfunctionality.so. But most Python needs are covered by its standard imports, and they are subject to "many eyes" quality assurance. You might wonder why I picked Python over Perl, Ruby and Lua. After all, most of the "interpreter" benefits I stated are equally applicable to all four. Here's why. So far, only Perl and Python are truely intertwined with Linux. I'd like to keep that number to a minimum. Throughout the past two decades, Perl's "many ways" philosophy has fallen into disfavor, as more and more shaky, indeterminant and unreadable code gets written in "many ways". And CPAN's a menace, and its tendancy to compile C code is failure waiting to happen. Lastly, as far as I know, among the four "interpreters" I mentioned, only Perl and Python have a stable of known good, well known and capable add-ons to assure one that any project you start in the language you can finish in the language. I'm not the king of Open Source, so I don't get to make others conform to what I say above. But when I develop something, I don't do it in C unless I can justify C: Otherwise I fall back on my default, Python. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Beginning of Devuan Dmenu Howto
On Mon, 2 Mar 2015 00:50:04 -0500 (EST) Peter Olson wrote: > > On March 2, 2015 at 12:07 AM Steve Litt > > wrote: > > > > > > Hi all, > > > > In a previous thread I discussed the usefulness and productivity of > > using dmenu in parallel with the hierarchical menu. I'm about 1/4 > > done, all of it dmenu general and not specific to Devuan, because I > > still don't know how Devuan's dmenu package will look. > > Does dmenu act without me pressing Enter? Thank you for pointing out an error in my documentation. I was confusing dmenu with UMENU. I will quickly fix my documentation. In fact, dmenu DOES NOT act without your pressing Enter. My bad. > I'm wondering what happens > when I make a typo that happens to match the name of a program I > never heard of. Unless you press Enter, nothing happens after the typo, except the wrong list elements get deleted, and Backspace gets you back to where you were before the typo. Thanks for making me aware of my mistake! I use dmenu so subconsciously that the brain in my head (as opposed to the brain in my hands) believed that you don't press Enter :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 12:05:34PM -0500, Steve Litt wrote: > On Mon, 02 Mar 2015 00:16:52 -0600 > "T.J. Duchene" wrote: > > > Frankly, I've also believe that > > interpreted languages should never be used for anything other than a > > teaching tool. If you must use something like that, at least use > > something that supports JIT to native code. > > If I were the king of all open source, and a programmer asked to write > a program in C, I would ask them to justify that. Will their > performance bottleneck be the code itself rather than the typist's > fingers? Will the time taken by their program materially affect the > overall performance of the computer? Do they need special access to the > metal that Python doesn't give them? Do they need to deal with a > library not accessible via Python, or even Lua? > It is surely not of fundamental relevance for the discussion, but I can't agree with this statement either :D Back in the days I thought that I would have eventually found "the perfect language", but then I realised that such a thing does not exist. Unless you develop just *one specific type* of software, in which case a perfect language *for that specific task* might exist. Otherwise, programming languages are in all respects quite similar to human languages: you will need to speak Spanish in Spain, Chinese in China, Russian in Russia, and so on. Maybe you can survive in most parts of the world with a little English (or a little Python, out of the metaphor), but it is undeniable that your communication potential increases more than linearly with the number of human languages you can fluently speak (or with the number and variety of programming language you master, out of metaphor)... 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
Re: [Dng] No way to use a prepartioned disk?
On Sun, Mar 01, 2015 at 11:26:55PM +0100, Adam Borowski wrote: > On Sun, Mar 01, 2015 at 05:07:10PM -0500, Hendrik Boom wrote: > > Interesting. I've used the Debian installer before, I think in the > > time of wheezy, and it worked with existing partitions. > > So does the one in jessie. > > I guess you did something wrong. As long as one partition is marked for > mounting as /, everything seems to work for me. I'm starting to suspect my problems are not with the installer, but with the way the hard drive had been partitioned previously. I'm going to have to investigate further. I did get to the point wher I would normally be assigning and creating partitions, but all I got to choose from were two drives -- the one I wanted to install on and the installation CD-on-a-USB-stick. The partitions I had previously created on the target drive were nowhere to be seen. My guess now is there was sometthing wrong with the partition table, preventing it from being recognised. Maybe it's not even there. I had copied partitions onto it using clonezilla. Perhaps something had gone wrong there. I'll report back. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Beginning of Devuan Dmenu Howto
On Mon, Mar 02, 2015 at 12:11:46PM -0500, Steve Litt wrote: > On Mon, 2 Mar 2015 00:50:04 -0500 (EST) > Peter Olson wrote: > > > > On March 2, 2015 at 12:07 AM Steve Litt > > > wrote: > > > > > > > > > Hi all, > > > > > > In a previous thread I discussed the usefulness and productivity of > > > using dmenu in parallel with the hierarchical menu. I'm about 1/4 > > > done, all of it dmenu general and not specific to Devuan, because I > > > still don't know how Devuan's dmenu package will look. > > > > Does dmenu act without me pressing Enter? > > Thank you for pointing out an error in my documentation. I was > confusing dmenu with UMENU. I will quickly fix my documentation. > > In fact, dmenu DOES NOT act without your pressing Enter. > > My bad. > > > I'm wondering what happens > > when I make a typo that happens to match the name of a program I > > never heard of. > > Unless you press Enter, nothing happens after the typo, except the > wrong list elements get deleted, and Backspace gets you back to where > you were before the typo. I note that the i3 window manager has this feature, binding to SpecialKey d. -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] three important UI features
On 02/28/2015 04:40 AM, Jaromil wrote: On Fri, 27 Feb 2015, Jonathan Wilkes wrote: Ok, that sounds like a plan. But which is the default DE for Devuan-- XFCE or Mate? It will be Xfce4, since Mate is somehow too big. Later on, we may still want to have a respin installer and/or liveCD with Mate default and anyway Mate is simple to apt-get install. However the default DE will be Xfce4 and we are also contributing to its code in order to keep it away from systemd lockin (thanks Dima!) https://bugzilla.xfce.org/show_bug.cgi?id=11574 Many VUAs love Xfce4 and its team is really a good example of talented open source developers with good concerns about usability, compatibility and resource consumption. we may want to backport a newer package ourselves with a more actual 4.12 (volunteers welcome). Ok. From what Steve has written it looks like there are a lot more possibilities than I imagined to get the minimal functionality I mentioned. Once Devuan gets some ISOs for a basic system up, I'll spend some time working within the default DE, and continue from there. -Jonathan ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 08:13 AM, KatolaZ wrote: On Mon, Mar 02, 2015 at 07:01:24AM -0500, Gravis wrote: [cut] Hi Gravis, I appreciate that, but I personally can't see how the problems of garbage collection in Java are related with good or bad programming practices, or with a supposedly terribly long chain of dependencies required by Perl and Python modules somebody mourned about earlier in the thread :) And I don't get how this relates to the development of Devuan, after all... Best KatolaZ @Katolz It's just a conversation, an exchange of views. It's marked as OT. Nothing wrong with that, and it is never intended to be a "put down" in any way. =) I find such to be a valuable measure of the community. it's good to get to know the minds and opinions of the people you may be working together with at some point. @Gravis We seem to think a lot alike on this subject. t.j. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 09:11 AM, Tor Myklebust wrote: I'm even more confused by your position than I was before. I can see your point. I'll try to explain more concisely. When I call something "overuse", I am referring to the ideas that an interpreted language must be used as "glue" between two bits of C code, that C is to be used "only as needed" or that interpreted languages are the preferential language choice for writing basic system utilities. These ideas has become more and more acceptable. They didn't used to be. I remember when interpreted languages were either hobbyist playtoys or teaching tools. Perl was used only for small jobs, and while shell was used extensively in System 5 init files, you were expected to do all serious work in C. A respectable percentage of today's Linux distribution is a kludge of rapid pre-existing hacks that do not always work well when layered. You have something like adduser or other command utilities written in Perl, which are then called by init scripts, which can then be called by still more scripting in the form of a X GUI application to manage users. At any stage it can be prone to unforeseen interpretation problems. I'm just asking at what point would it be more beneficial to simply code a library in something like C, and be done with it? Perl, Python, and Java,and a number of other languages just do not function well for certain kinds of tasks that require efficient resource management over time, yet they are constantly being used by the opensource community today in places were it might be advisable to reconsider. Why pick on perl? Only because Perl makes itself the biggest target for example. I don't HATE Perl. I've even written a lot of Perl code in my day. I also recognize it for what it is. Perl is something that should be restricted to unimportant, small user jobs that won't be used too often, and most certainly never used with root permission. As everyone knows, Perl has a very ugly history of permissions flaws, that can rear its head if someone does not compile it properly. Why not pick on the huge number of low-quality C libraries that are out there? Yes, there can be low quality libraries in C. The main argument for using Perl, or other similar languages, instead of C is that there is less chance of errors (and thus better software) and you spend less time using it. If as you point out you can have can have crappy code anywhere so that tosses out the first argument. The second, that Perl is a timesaver is entirely subjective. With the right libraries, and enough actual use, anyone can write a small utility just as efficiently in C or a similar language. . I don't think you said what you were trying to say. Judicious use of abstraction is what lets us write useful software in the first place. True, however, there also comes a point where writing software in highly abstracted languages (usually the interpreted sort) has diminishing returns. I feel that they have been overused in the Linux ecosystem as whole. My whole rant is really just chatting with the community and seeing if anyone else shares that opinion. If you don't personally, that's just fine by me. =) Have a great day! t.j. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 10:49 AM, KatolaZ wrote: On And as they have already explained above, this is exactly the reason why some non-critical Debian system utilities (such as debconf or adduser) are written in Perl or Python :) And they were so cool to manage to reduce the dependencies of these packages to the bare minimum (basically, the interpreter). Personally, I'd rather they were written in C, if only to avoid the "scripts calling scripts that call scripts" scenario, KatolaZ. You don't have to agree with me. The fact that you don't is actually why we are having this chat. I want to hear your thoughts. I would like to point out that this is not just a curse of Debian. Also other distros and other operating systems (like FreeBSD) use perl and python scripts for some non-critical system software, True, enough! just because sometimes you can do in three lines of Perl what would require a few hundred lines of C (plus a few additional libraries)... That is not entirely true. I've heard that said many times. I've deliberately written code in C instead of Perl, just to test that assumption. Personally, I've found it to be just that: an assumption. When you code in Perl, you are using subroutines and libraries that were incorporated into Perl core.The fact you are calling an entire subroutine when you "split" strings in Perl is no different than having a C string library. You call the library to do the work. You don't care how it does it, only that you get the results. C gets a bad reputation because a percentage of programmers never learned how to prevent buffer overflows or leaks is all. That is certainly not C's fault. You can do both of those things in C#, which is supposedly "bullet-proof." ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 11:05 AM, Steve Litt wrote: If I were the king of all open source, and a programmer asked to write a program in C, I would ask them to justify that. Will their performance bottleneck be the code itself rather than the typist's fingers? Will the time taken by their program materially affect the overall performance of the computer? Do they need special access to the metal that Python doesn't give them? Do they need to deal with a library not accessible via Python, or even Lua? We just see things differently. My first question would be: is there are a justified reason NOT to use C? In opensource, more often then not, small tasks get combined into big tasks, via scripting or whatever - into huge morasses of complex complicated scripts. It can lead to serious problems, which I personally prefer to avoid. I suppose in that way I am somewhat more BSDish than your average Linux user. My concern is usually what maximizes efficiency over the long term. Because here's the thing. We all say we're great programmers, but somehow, on lots of software, buffers get overrun. Pointers go errant. Programs proceed after failed mallocs. Malloc/free loops somehow start to accumulate more allocation than freeing. None of this is an issue in Python. In Python, programmer mistakes tend to affect the data, not the system. Python long ago solved the vast majority of security problems: It's secure, and when it's not, because of its millions of users, you find out fast. Yes, I know that Python's got that 2.x vs 3.x problem. Yes, I know that a lot of people hate Python's significant whitespace. Yes, I know that a Python import is a dependency, just as sure as libarbitraryfunctionality.so. But most Python needs are covered by its standard imports, and they are subject to "many eyes" quality assurance. You might wonder why I picked Python over Perl, Ruby and Lua. After all, most of the "interpreter" benefits I stated are equally applicable to all four. Here's why. So far, only Perl and Python are truely intertwined with Linux. I'd like to keep that number to a minimum. Throughout the past two decades, Perl's "many ways" philosophy has fallen into disfavor, as more and more shaky, indeterminant and unreadable code gets written in "many ways". And CPAN's a menace, and its tendancy to compile C code is failure waiting to happen. Lastly, as far as I know, among the four "interpreters" I mentioned, only Perl and Python have a stable of known good, well known and capable add-ons to assure one that any project you start in the language you can finish in the language. I'm not the king of Open Source, so I don't get to make others conform to what I say above. But when I develop something, I don't do it in C unless I can justify C: Otherwise I fall back on my default, Python. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
Sorry stupid Mail program sent it before I finished. Keyboard seems to be having a bad day. On 03/02/2015 11:05 AM, Steve Litt wrote: Because here's the thing. We all say we're great programmers, but somehow, on lots of software, buffers get overrun. Pointers go errant. Programs proceed after failed mallocs. Malloc/free loops somehow start to accumulate more allocation than freeing. None of this is an issue in Python. In Python, programmer mistakes tend to affect the data, not the system. Python long ago solved the vast majority of security problems: It's secure, and when it's not, because of its millions of users, you find out fast. Let's just say that I EMPHATICALLY disagree with you on the subject of Python and leave it at that. I'm afraid I come from a part of the universe where Python is not embraced, but utterly despised for syntax reasons. Yes, I know that Python's got that 2.x vs 3.x problem. Yes, I know that a lot of people hate Python's significant whitespace. Yes, I know that a Python import is a dependency, just as sure as libarbitraryfunctionality.so. Those are annoyances, I agree. You might wonder why I picked Python over Perl, Ruby and Lua. After all, most of the "interpreter" benefits I stated are equally applicable to all four. Here's why. So far, only Perl and Python are truely intertwined with Linux. I'd like to keep that number to a minimum. On that, we definitely agree! I'd prefer less, but if we have to have at least one, I'd rather pick one and stick with it consistently - even if in the end that happened to be Python, and that all the interpreted scripting in a distribution be done in one and only one language, rather than a handful. Throughout the past two decades, Perl's "many ways" philosophy has fallen into disfavor, as more and more shaky, indeterminant and unreadable code gets written in "many ways". Forcing the "one way" using Python hardly leads to efficient code either, IMHO. And CPAN's a menace, and its tendancy to compile C code is failure waiting to happen. On that we also agree: CPAN is a menace. Just to be clear, I don't blame C for that. At least not any more than I blame Python for using C code itself. I blame CPAN for crappy test modules and poor version control. Lastly, as far as I know, among the four "interpreters" I mentioned, only Perl and Python have a stable of known good, well known and capable add-ons to assure one that any project you start in the language you can finish in the language. On that we can agree somewhat. I'll be honest in saying that Python would gain much more respect from me if it were formally standardized. I'd prefer that every certified version was guaranteed to run a certain level of compatible code. I'm not a fan of "de-facto" languages. t.j ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, 2 Mar 2015, T.J. Duchene wrote: A respectable percentage of today's Linux distribution is a kludge of rapid pre-existing hacks that do not always work well when layered. You have something like adduser or other command utilities written in Perl, which are then called by init scripts, which can then be called by still more scripting in the form of a X GUI application to manage users. At any stage it can be prone to unforeseen interpretation problems. This is indeed true, but it seems like a social problem rather than a technical problem. People can, and will, write garbage software no matter what tools they have. It might pay to let them do this with as little pain as possible so they can go back to working on the thing they were actually interested in doing. It sounds here like you don't like that your X application is running scripts, probably incorrectly, to do basic stuff. And how running a script can fail, with error codes like "too many open files" or "too many processes" or "not enough memory" when the task in question doesn't obviously involve allocating memory or spinning up a process. If you're in the mood to lay blame in a situation like this, I sugges directing it at the X application's author rather than the author of the script the application calls. I'm just asking at what point would it be more beneficial to simply code a library in something like C, and be done with it? I think the answer to this question is more complicated than can be described by a "tipping point" in a cost-benefit analysis. I think it's context-dependent and I think it can change over the lifetime of the software. Performance concerns, for instance, often crop up later in the lifetime of a project once it has a sizable userbase (or once somebody asks for the resource-intensive feature enough times). Should we code everything in C from the start just so we don't have to handle the performance problems in the unlikely event that the project succeeds? Maybe, but what if that constraint makes the project take quite a bit longer? And what if that reduces its chances of success? Performance concerns can cut the other way, too, under the name "scalability." Because it's easier to write really fast C code, you can get a lot farther with your really fast C code before hitting a performance wall. That sounds good, but it means your code can evolve into a bigger mess by the time you have to address your choice of data structures, or parallelisation, or distribution. Perl, Python, and Java,and a number of other languages just do not function well for certain kinds of tasks that require efficient resource management over time, yet they are constantly being used by the opensource community today in places were it might be advisable to reconsider. This is true. I've found it's not that hard to avoid running crap perl and python software. It's interesting that you'd mention Java here. I don't much like the Java language or the Java programming culture, but Java bytecode has the interesting property that, with a little plumbing, one can send executable code over the network and have it run on a remote machine. This actually winds up being useful for large-scale data crunching, where you want to move the code to the data rather than the data to the code wherever possible. I wouldn't know how to build a system that does this in C (for instance) that isn't brittle. Why pick on perl? Only because Perl makes itself the biggest target for example. I don't HATE Perl. I've even written a lot of Perl code in my day. I also recognize it for what it is. Perl is something that should be restricted to unimportant, small user jobs that won't be used too often, and most certainly never used with root permission. As everyone knows, Perl has a very ugly history of permissions flaws, that can rear its head if someone does not compile it properly. Why not pick on the huge number of low-quality C libraries that are out there? Yes, there can be low quality libraries in C. The main argument for using Perl, or other similar languages, instead of C is that there is less chance of errors (and thus better software) and you spend less time using it. If as you point out you can have can have crappy code anywhere so that tosses out the first argument. The second, that Perl is a timesaver is entirely subjective. With the right libraries, and enough actual use, anyone can write a small utility just as efficiently in C or a similar language. It depends on what the utility is. C does not support certain useful forms of abstraction available in other languages. (I'm not talking about inheritance here. Generics and mixins are to my knowledge both impossible to do in a performant and syntactically transparent way in C. Ditto for anonymous functions. The way you emulate tagged unions in C---a struct with a tag field and a union member---is a li
Re: [Dng] three important UI features
Later on, we may still want to have a respin installer and/or liveCD with Mate default and anyway Mate is simple to apt-get install. With XFCE 4.12, just released any interest I had in Mate is now diminished considerably. I've nothing against Mate personally, but objectively speaking, XFCE provides an equivalent or better featureset with a lot less clutter. The XFCE codebase seems better maintained than a rework of Gnome 2, IMHO. My experience with Mate has been less than satisfactory lately. Differing distributions like Debian sid and OpenSUSE seem to have issues with mate-session causing UI crashes.I'd think it will take some serious work before a Debian Mate respin, or that Mate itself can be taken as seriously as XFCE at present. Many VUAs love Xfce4 and its team is really a good example of talented open source developers with good concerns about usability, compatibility and resource consumption. The reason we like it? Gradual improvement over radical change. we may want to backport a newer package ourselves with a more actual 4.12 (volunteers welcome). What do you need specifically? I'd be willing to offer some time as long as it is a discrete request, with a beginning and end. I've already compiled 4.12 once. t.j. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/02/2015 05:33 PM, Tor Myklebust wrote: This is indeed true, but it seems like a social problem rather than a technical problem. People can, and will, write garbage software no matter what tools they have. It might pay to let them do this with as little pain as possible so they can go back to working on the thing they were actually interested in doing. It sounds here like you don't like that your X application is running scripts, probably incorrectly, to do basic stuff. And how running a script can fail, with error codes like "too many open files" or "too many processes" or "not enough memory" when the task in question doesn't obviously involve allocating memory or spinning up a process. If you're in the mood to lay blame in a situation like this, I sugges directing it at the X application's author rather than the author of the script the application calls. I'm not pointing fingers at any particular author, just the prevailing wisdom of the day. I think the answer to this question is more complicated than can be described by a "tipping point" in a cost-benefit analysis. I think it's context-dependent and I think it can change over the lifetime of the software. Performance concerns, for instance, often crop up later in the lifetime of a project once it has a sizable userbase (or once somebody asks for the resource-intensive feature enough times). Should we code everything in C from the start just so we don't have to handle the performance problems in the unlikely event that the project succeeds? Maybe, but what if that constraint makes the project take quite a bit longer? And what if that reduces its chances of success? If programming were that "black and white" I would agree with you. However, C in general is the language in which other languages are written. The ease with which you can link C object code to whatever language you happen to using pretty much renders that concern moot. Performance concerns can cut the other way, too, under the name "scalability." Because it's easier to write really fast C code, you can get a lot farther with your really fast C code before hitting a performance wall. That sounds good, but it means your code can evolve into a bigger mess by the time you have to address your choice of data structures, or parallelisation, or distribution. I've seen plenty of scaling arguments, and some of them are perfectly valid arguments, but many of them are also just suppositions based on the idea that C can't OOP. It's interesting that you'd mention Java here. I don't much like the Java language or the Java programming culture, but Java bytecode has the interesting property that, with a little plumbing, one can send executable code over the network and have it run on a remote machine. This actually winds up being useful for large-scale data crunching, where you want to move the code to the data rather than the data to the code wherever possible. I wouldn't know how to build a system that does this in C (for instance) that isn't brittle. There is no magic to it. Java's core is usually written in C after all. Realistically, the reason Java can do that is that Java bytecode is processor generic. You could theoretically do that with C as long as the processors are the same. It depends on what the utility is. C does not support certain useful forms of abstraction available in other languages. (I'm not talking about inheritance here. Generics and mixins are to my knowledge both impossible to do in a performant and syntactically transparent way in C. Ditto for anonymous functions. The way you emulate tagged unions in C---a struct with a tag field and a union member---is a little scary in any large code base because incomplete 'switch' statements won't raise compile-time warnings.) Generics are little more than data in a buffer, IMHO. All you need do is cast them as you see fit. The fact that other languages offer you syntactic sugar to do it, is just fine too. The real comment is that the language you refer to is not more capable. You are running it on the same hardware. The difference is that the other language just makes it easier for you in some cases, not necessarily better. I think you have aimed your criticism at the wrong target. It is annoying that "new" and "user-friendly" have both become synonymous with "does not work under heavy load or unusual conditions" in Linux. It wasn't always that way. But I would look toward the people building brittle stuff that instead of the guy who wrote adduser if I wanted to diagnose the problem. I would rather address the disease than the symptom. I'd rather see that the root cause: the cathedral of dependencies gets taken down a notch. Doing that starts at the beginning, IMHO. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 04:12:02PM -0600, T.J. Duchene wrote: > > On 03/02/2015 09:11 AM, Tor Myklebust wrote: > > > >I'm even more confused by your position than I was before. > > > > > I can see your point. I'll try to explain more concisely. > > When I call something "overuse", I am referring to the ideas that an > interpreted language must be used as "glue" between two bits of C code, that > C is to be used "only as needed" or that interpreted languages are the > preferential language choice for writing basic system utilities. These > ideas has become more and more acceptable. They didn't used to be. I > remember when interpreted languages were either hobbyist playtoys or > teaching tools. Perl was used only for small jobs, and while shell was used > extensively in System 5 init files, you were expected to do all serious work > in C. > > A respectable percentage of today's Linux distribution is a kludge of rapid > pre-existing hacks that do not always work well when layered. You have > something like adduser or other command utilities written in Perl, which are > then called by init scripts, which can then be called by still more > scripting in the form of a X GUI application to manage users. At any stage > it can be prone to unforeseen interpretation problems. > > I'm just asking at what point would it be more beneficial to simply code a > library in something like C, and be done with it? > > > Perl, Python, and Java,and a number of other languages just do not function > well for certain kinds of tasks that require efficient resource management > over time, yet they are constantly being used by the opensource community > today in places were it might be advisable to reconsider. Hi TJ, The languages you mention are used in industry, extensively, in heavily loaded applications. Even the much derided PHP, has continued to hold a huge niche. Perl has DBI and friends, making it possible to create pluggable backend-independent database applications. Booking.com is an example of large-scale user that is a perl house. Access to external libraries from within dynamic languages can bring in the advantages of compiled langauges. One can develop an application in Python or Perl, then later use profiling to know where to optimize, and to move hotter parts of the code to C or C++. I'm reading that Python has a better foreign call interface than Perl. There is an issue of finding the best modules for a purpose on CPAN, however there are excellent modules for many, many purposes, often well documented and with good test coverage. Personally, I am pleased that I can use sockets through a dynamic language like Perl without having to be an expert, write terminal applications without being a cognosenti on the intricacies of managing terminals, read and write files without extensive knowledge of file-system minutae. Lower-level expertise in a developer is usually an advantage, however I don't think we should blame dynamic langauges for making it possible for people to code without knowing all the gory details at the lowest level. When I think of Apache with mod_perl, which at one point served a lot of pages, and the current work in Catalyst I am sure that one can develop heavily loaded applications in dynamic languages that don't leak resources/memory. Was I being trolled? ^^ cheers, Joel > > > >Why pick on perl? > Only because Perl makes itself the biggest target for example. I don't HATE > Perl. I've even written a lot of Perl code in my day. I also recognize it > for what it is. Perl is something that should be restricted to unimportant, > small user jobs that won't be used too often, and most certainly never used > with root permission. As everyone knows, Perl has a very ugly history of > permissions flaws, that can rear its head if someone does not compile it > properly. > > >Why not pick on the huge number of low-quality C libraries that are out > >there? > Yes, there can be low quality libraries in C. The main argument for using > Perl, or other similar languages, instead of C is that there is less chance > of errors (and thus better software) and you spend less time using it. If > as you point out you can have can have crappy code anywhere so that tosses > out the first argument. The second, that Perl is a timesaver is entirely > subjective. With the right libraries, and enough actual use, anyone can > write a small utility just as efficiently in C or a similar language. > . > > > >I don't think you said what you were trying to say. Judicious use of > >abstraction is what lets us write useful software in the first place. > > True, however, there also comes a point where writing software in highly > abstracted languages (usually the interpreted sort) has diminishing returns. > I feel that they have been overused in the Linux ecosystem as whole. My > whole rant is really just chatting with the community and seeing if anyone > else shares that opinion. If you don't personally,
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
Are you guys ever gonna run out of gas? This thread has pretty much taken over my Inbox . . . ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
> On 03/02/2015 08:13 AM, KatolaZ wrote: > > I appreciate that, but I personally can't see how the problems of > garbage collection in Java are related with good or bad programming > practices, it's an problem with garbage collection in general, not just with Java. > or with a supposedly terribly long chain of dependencies > required by Perl and Python modules somebody mourned about earlier in > the thread :) And I don't get how this relates to the development of > Devuan, after all... this specifically relates to your discussion with TJ that you "[cut]" out of your response. TJ: "Contrary to what most "modern" programmers would like to promote, I do not believe for one second that mandatorily garbage collected, bounded languages create better code design." KatolaZ: "I honestly can't see all this failing around of code written in Python, Perl or Ruby :)" you said you didn't see the code failing, i explained why you didn't see it and that it is happening. --Gravis On 03/02/2015 08:13 AM, KatolaZ wrote: > > On Mon, Mar 02, 2015 at 07:01:24AM -0500, Gravis wrote: > > [cut] > > Hi Gravis, > > I appreciate that, but I personally can't see how the problems of > garbage collection in Java are related with good or bad programming > practices, or with a supposedly terribly long chain of dependencies > required by Perl and Python modules somebody mourned about earlier in > the thread :) And I don't get how this relates to the development of > Devuan, after all... > > Best > > KatolaZ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
consider grouping your emails as "conversations" as it is a wonderful option for organizing mailing list threads. instructions to enable on yahoo mail: https://help.yahoo.com/kb/conversations-feature-enabled-disabled-sln15805.html --Gravis On Mon, Mar 2, 2015 at 8:36 PM, Go Linux wrote: > Are you guys ever gonna run out of gas? This thread has pretty much taken > over my Inbox . . . > ___ > 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] Devuan Weekly News XIV - Where no toy has gone before
# Devuan Weekly News Issue XIV __Volume 002, Week 9, Devuan Week 14__ Released 03/03/12015 [HE](why-he) https://git.devuan.org/Envite/devuan-weekly-news/wikis/past-issues/volume-02/issue-014 ## Editorial It's hard to believe it's winter when you have to mop the sweat out of your keyboard, but the intensity of this week's conversations, and @golinux's [penguins][0] made thinking about cold easier. Cold reigns in deep space as well and Devuan users will appreciate the identity moving away from toyland: although Debian Jessie refers to an adventurous toy cowgirl with an attitude, Devuan's Jessie refers to a place no toy has ever gone before. Exit the naughty `Sid` brat, welcome `Ceres`, largest object in the asteroid belt, and the first minor planet discovered in the 19th Century. That's right, [Devuan release codenames][1] will be named after minor planets of our solar system. As far as visual identity goes, and although the logo still consumes a significant bit of attention, it won't be revealed before the code: part of the distro's publishing policy is to deliver working code before a shiny image. Welcome to Issue XIV of the DWN, cooked _al dente_ by your interim editor, @hellekin, with the invaluable help of @golinux and @joerg_rw. ## Last Week in Devuan ### [Debian Problems with Jessie][2] T.J.Duchene advises not to bring "Debian mud" to the list: "Devuan does not need to justify its own existence." Here comes the largest thread this week: a swashbuckling introspective and speculative bubble visiting what's wrong with collective creation of software. (It all started with _Simple Backgrounds_, go figure.) ### [Three Important UI Features][3] Last week Jonathan Wilkes introduced the idea of improving the features for the default devuan desktop. Wolfgang Pirker proposes two solutions for the "find apps as you type" #2 feature. Feature #3 "menu on the Super key" can be addressed with `dmenu`. A consensual voice raises in favor of Xfce as the default desktop environment (DE), which comes with its own implementation equivalent to what dmenu provides. In passing, for your hacker jeopardy, here's a funky compiler flag in `Enlightenment` that will probably break the layout of many screen applications displaying this: `--enable-i-really-know-what-i-am-doing-and-that-this-will-probably-break-things-and-i-will-fix-them-myself-and-send-patches-aba`. ### [Xfce Desktop Environment in Devuan][4] As `Xfce 4.12` was released this week on the 28th of February, it was also chosen to become the default DE in Devuan, which makes it the first _non-systemd_ difference between cowgirl Jessie and planet Jessie. David Harrison talked with the Xfce team, and @jaromil confirms existing coordination and good terms between Devuan and Xfce. ### [Logind Alternative][5] Oz Tiram introduces the `ConsoleKit2` fork that does not depend on `systemd-logind`. Svante Signell offers to package it for Devuan. Dima Krasner reminds that "ConsoleKit2 was already packaged by Max, but we don't need it in the Jessie cycle because the logind dependency was dropped from all packages." ### [Simple Backgrounds][6] Hendrik Boom is concerned not to delay the first release for designing the project's visual identity (and he's right). As @jaromil puts it: "Devuan is sugar-free and doesn't makes your computer fat :^)" See the editorial. ### More of Devuan Logo Discussions abound regarding the potential Devuan logo. Linuxito announces a [graphical version of the survey][7], warning that it's informative, and Anto notes that a logo without matching text "would look strange". In [another thread][8], Hendrik Boom suggests using the Milky Way as the basis for the logo (that was before the release code names were announced, but it was in the air). Tzu-Pei Chen shows that a single-arm spiral galaxy exists, which Hendrik qualifies as "debian galaxy", leaving the interpretation of the comment's depth to the astute reader. Neo Futur engages in the [philosophy of KISS][9]. ### The Valentine <3 Pre-Release Support More people come with feedback over the Valentine Pre-Release ISO. Please [report any issue][10] with this release so the team can ensure these are gone in the next batch. John Morris reports [quite a few issues][11], some of them coming from Debian Installer itself. His verdict: "most problems were fixable and process 1 is init so Winning!" Hendrik Boom plans [to install Valentine pre-alpha on real hardware][12]. So far he got the hardware to boot from USB using the `isohybrid` method as `dd` would not work, but got stuck with manual partitioning: the disk seems not to offer a safe option to [preserve existing partitions][13]. He also mentions a long-standing but minor bug in debootstrap that prevents Debian from offering multiple inits. Svante Signell narrows down the issue to Debian bug #668001, and a maintainer refusing to include the patch in Jessie. Hint: that patch _will_ be in Devuan Jessie. Hendrik also ha
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 04:35:24PM -0600, T.J. Duchene wrote: [cut] > >I would like to point out that this is not just a curse of > >Debian. Also other distros and other operating systems (like FreeBSD) > >use perl and python scripts for some non-critical system software, > True, enough! > > >just because sometimes you can do in three lines of Perl what would > >require a few hundred lines of C (plus a few additional libraries)... > That is not entirely true. I've heard that said many times. I've > deliberately written code in C instead of Perl, just to test that > assumption. Personally, I've found it to be just that: an > assumption. Well, if you found that *for your particular tasks* C can replace Perl or Python, I believe you. But it's just not true that this should be the case for everybody else, in every possible use case. I have always had a personal preference for C, and I think it is absolutely winning in many different contexts. That's exactly why it's still around after more than 40 years, and why it will probably be around for the next 40 or so. But you can't deny that other languages exist, and can be useful (even *more* useful than C for certain tasks), and there might exist also good coders out there being able to write good programs with these other languages you despise :) Unfortunately, the world is not just black or white, when it comes to languages. And I am among those who believe that the world *IS* and *SHOULD BE* absolutely black or white, in many other respects... :D > > > When you code in Perl, you are using subroutines and libraries that > were incorporated into Perl core.The fact you are calling an > entire subroutine when you "split" strings in Perl is no different > than having a C string library. You call the library to do the > work. You don't care how it does it, only that you get the results. > C gets a bad reputation because a percentage of programmers never > learned how to prevent buffer overflows or leaks is all. That is > certainly not C's fault. > And I can mantion dozens of counterexamples in which Perl or Python would solve the task more easily than C. Just to give you an idea, I have been doing quite a bit of XML parsing, mainly to convert data sets of all sorts in a reasonable (ASCII) format. Well, I have done it both in C and Python, so I think I can make a fair comparison between the two *for this particular task* and for *my specific needs*. Usually the C implementation of a non-trivial XML parser might require a couple of days to be finished and be able to digest the whole schema (you have to construct the data structure piece by piece, and to pass around a lot of garbage, and to be sure that you don't have leaks anywhere, and to catch and handle errors by hand...). Conversely, the Python implementation is usually ready in less than two hours, at most, and gives you the same set of functionalities at the cost of a slightly longer processing time (in the range of tens of seconds, or minutes, in the worst case). And if I have to use that code only once (as it is *very often* the case with 98% of the code), then the Python way is overall far better, faster, easier and convenient than any other thing you can conceive. 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
[Dng] [dng] vdev status update
Hey everyone, Sorry the weekly vdev update is a day late this time. I've been traveling most of this week, so I haven't had much time to work on it. However, I am happy to report that: * Thanks to Isaac Durham, vdev should now create the /dev/by-label symlinks for disks. * vdevfs (the filesystem half of vdev) will preserve device nodes across crashes (NOT YET COMMITTED). * vdevfs will delegate storage of its API data (i.e. stuff that would normally have to be pulled from a udevadm-like tool) to tmpfs, mounted at /dev/vdev by default. This reduces the complexity of the implementation and increases I/O performance without losing functionality. This closes issue #15. * fskit [1], a filesystem library I built for making API filesystems (which vdevfs uses), has received several bugfixes to remove some deadlock conditions that occur when using certain combinations of inode consistency disciplines. Also, some use-after-free bugs have been discovered and fixed. Both were discovered while testing runfs [2], which just got a trunc(2) implementation. It's going to be a busy week for me, but I hope to have at least one day free this weekend to address vdev issues #8 and #11. Best, Jude [1] https://github.com/jcnelson/fskit [2] https://github.com/jcnelson/runfs ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Mon, Mar 02, 2015 at 02:33:27PM -0600, T.J. Duchene wrote: > @Katolz > > It's just a conversation, an exchange of views. It's marked as OT. > Nothing wrong with that, and it is never intended to be a "put down" > in any way. =) I find such to be a valuable measure of the > community. > > it's good to get to know the minds and opinions of the people you > may be working together with at some point. Totally agree :) I am the first one stimulating this kind of discussions, when the need arises. I was only scared of other mailinglisters complaining about an endless thread... :D HND KatolaZ ^^^ :P -- [ 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
