Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Wed, Mar 04, 2015 at 11:49:20AM +0100, shraptor shraptor wrote: I consider myself of moderate coding skills and I like shell. I learnt coding in basic, modula2 and some c. If you liked Modula 2, you might want to look at Modula 3. Same syntax, but completely different language. -- 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
On 03/02/15 23:23, Gravis wrote: consider grouping your emails as conversations as it is a wonderful option for organizing mailing list threads. *** Thanks for this, but the topic having drifted a lot: the thread should also have been renamed. If any of you would like to contribute a summary, you're welcome to chime in to #devuan-news. Otherwise I doubt that anyone wants to cover it in the next issue of DWN because it's way off-topic and a lot of reading. Maybe that could be a way to reset the thread into something workable. I doubt people coming to the mailing list at this point will understand anything about simple backgrounds or Debian problems with Jesse (sic). [OT] is the last bit of information in the Subject. == hk -- _ _ We are free to share code and we code to share freedom (_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/ ___ 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 Wed, Mar 04, 2015 at 01:39:55AM -0600, T.J. Duchene wrote: On 03/03/2015 09:07 PM, Hendrik Boom wrote: As time passed, they kept finding new uses for their scripting language. Occasionally they would realize and existing module needed major new functinoality, and it was easier to write the new version in Scheme than to modify the old. Over two years or so, they ended up replacing their C code, piece by piece, with Scheme code. In the end they had a system that was mostly written in Scheme, was more reliable, did more, ran faster, and was only about 3 lines of Scheme. When I say this, please do not think that I am making remarks against your experience or observations, but I just don't get it. I don't see how that can be the case. The version of Scheme that you mention is specifically implemented on top of C, so your remarks cannot be entirely true, nor make any sense to me at all. Scheme can't be more reliable, do more, or run faster, especially if it implemented on top of C or even converted into system object code by the very same C compiler. No doubt the programmers could in principle have written the same code that Gambit generated. I say in principle because the generated C code is bulky, uncommented, and well-nigh incomprehensible. They could have even written equivalent code in well ant truly commented readable C code. But to someone new coming to the project, any 200,000 lines of code are incomprehensible, regardless of quality. What made the difference is that 30,000 lines of code are more comprehensible than 200,000, just by sheer volume. It was easier to understand what the code was doing. So they could see what was really going on and replace algorithms easily. The increase in comprehensibility might have been due simply to the reduced volume of code. But the powerful metaprogramming features of Gambit may also have helped. They could adapt the language to their applications semantics, making it all more comprehensible. And it may also have reduced the total amount of code they needed to write. The entire statement is non sequitur. I will that any specific compiler, even a C compiler, can be total and utter crap, if it is badly implemented. I will also agree that individuals' programming skills can be massively lacking. It is possible that they were more skilled with Scheme than C, but that does not make Scheme superior to C by any objective standard. It was really a win for the high-level, garbage-collected language. I've used enough GC languages to know the problems that they try to solve. It's a good idea to try, really, and it is a fantastic debugging tool when testing code. It's a fantastic debugging tool only in a run-time secure language. Then you can rely on things like pointers pointing to the kind of thing they should when interpreting debugging output and making deductions about what yout code did. If your language isn't run-time secure, combining garbage collection and undebugged code is a disaster. The Boehm garbage collector may well *not* be your friend when writing C or C++. But that is all it is good for. There are problems in which the data structures are so inherently tangled that garbage collection is the *only* practical way to manage memory. I agree that most programs are not of this type. One use of a garbage collector is in fsck. It garbage collects file systems. This was especially useful in the days when you could hard-link directories. No one has ever created a fail-proof GC design. When the GC model fails, it makes fixing your code difficult, sometimes even impossible to correct without a patch for the entire runtime, not to mention you may need to recompile everything regardless after you get it. The same is true for a compiler that generates subtly bad code. I don't know of any bug-free compilers. Do you? Well, actually, I was once told that the Algol 60 compiler written by Kruseman Aretz was bug-free. But I have no direct experience with it. I'm told that his friends, as an April Fool's joke, once carefully faked up a program listing and its (wrong) output and claimed they had detected a bug after the compiler had been running correctly for years. He caught on when he realised that the page numbers on the program listing were not *quite* printed as his compiler would have written them. When someone can design a GC language that solves leaks and buffer overflows 100% of the time, I'll give them all the praise they deserve. Buffer overflows can be stopped by a language. Until, of course, you step outside the language because you need to use code that does things not allowed in the language. Leaks are more difficult. GC can prevent dangling pointers, but determining for sure whether any piece of storage will ever be used again is Turing-undecidable. Systems languages that are type- and storage- secure handle this pragmatically. They
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
I think it is very likely Henrik, that we will never agree entirely on the subject. =) Which is okay with me and should be okay with you, too. We agree that particular GC is doomed to be flawed. As something that cannot be avoided, the potential for disasterous bugs that cannot be fixed by the application programmer outweigh any benefits that a GC provides in my opinion. It's important to note that generally speaking a more accurate GC mechanism is inherently more complex and wastes more and more resources including battery power and user time. For me, this goes against the first maxim of programming: keep it simple. As you say, compilers are not perfect either, but your average compiler, converting code to assembly, is well understood and fairly straightforward. Garbage collection is not nearly as straightforward. You aren't even sure it will work until the code is actually executed. It's a dynamic process, and guaranteeing reliability is a problem. Ultimately in the real world, the only effective mechanism for fixing the problems that GC tries to address is a programmer trained to clean up after herself. That's why I don't buy into the idea that GC languages are better. I believe they create the worst kind of programmers: lazy. t.j. On Wed, Mar 4, 2015 at 1:04 PM, Hendrik Boom hend...@topoi.pooq.com wrote: On Wed, Mar 04, 2015 at 01:39:55AM -0600, T.J. Duchene wrote: On 03/03/2015 09:07 PM, Hendrik Boom wrote: As time passed, they kept finding new uses for their scripting language. Occasionally they would realize and existing module needed major new functinoality, and it was easier to write the new version in Scheme than to modify the old. Over two years or so, they ended up replacing their C code, piece by piece, with Scheme code. In the end they had a system that was mostly written in Scheme, was more reliable, did more, ran faster, and was only about 3 lines of Scheme. When I say this, please do not think that I am making remarks against your experience or observations, but I just don't get it. I don't see how that can be the case. The version of Scheme that you mention is specifically implemented on top of C, so your remarks cannot be entirely true, nor make any sense to me at all. Scheme can't be more reliable, do more, or run faster, especially if it implemented on top of C or even converted into system object code by the very same C compiler. No doubt the programmers could in principle have written the same code that Gambit generated. I say in principle because the generated C code is bulky, uncommented, and well-nigh incomprehensible. They could have even written equivalent code in well ant truly commented readable C code. But to someone new coming to the project, any 200,000 lines of code are incomprehensible, regardless of quality. What made the difference is that 30,000 lines of code are more comprehensible than 200,000, just by sheer volume. It was easier to understand what the code was doing. So they could see what was really going on and replace algorithms easily. The increase in comprehensibility might have been due simply to the reduced volume of code. But the powerful metaprogramming features of Gambit may also have helped. They could adapt the language to their applications semantics, making it all more comprehensible. And it may also have reduced the total amount of code they needed to write. The entire statement is non sequitur. I will that any specific compiler, even a C compiler, can be total and utter crap, if it is badly implemented. I will also agree that individuals' programming skills can be massively lacking. It is possible that they were more skilled with Scheme than C, but that does not make Scheme superior to C by any objective standard. It was really a win for the high-level, garbage-collected language. I've used enough GC languages to know the problems that they try to solve. It's a good idea to try, really, and it is a fantastic debugging tool when testing code. It's a fantastic debugging tool only in a run-time secure language. Then you can rely on things like pointers pointing to the kind of thing they should when interpreting debugging output and making deductions about what yout code did. If your language isn't run-time secure, combining garbage collection and undebugged code is a disaster. The Boehm garbage collector may well *not* be your friend when writing C or C++. But that is all it is good for. There are problems in which the data structures are so inherently tangled that garbage collection is the *only* practical way to manage memory. I agree that most programs are not of this type. One use of a garbage collector is in fsck. It garbage collects file systems. This was especially useful in the days when you could hard-link directories. No one has ever created a fail-proof GC design. When the GC model fails,
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On 03/03/2015 07:19 PM, Nuno Magalhães wrote: So what you're saying is that all languages are syntactic sugar over assembly? :) Not at all. C was designed specifically to allow code to be portable, instead of assembly which is not. I said usually. What I mean is that many arguments in favour of specific high level languages are mostly syntactic sugar arguments. Those languages are usually implemented in C, and the advantages that they supposedly offer can be achieved using C. More and more i see it'll be more work / take longer to implement / be more complex as developer excuses to use more user-friendly languages like java (and less and less developers learning C in college so they're biased). Yes. I can't speak for others, but I can implement far more cleanly designed and reliable solutions using C than other choices. I can certainly write less code using Python or Perl, but I can do exactly the same thing with C by using a library. IMHO less code is not better over the long term. Having a clean design from the beginning trumps fast and dirty that most people use every time. I can't tell you how much time I have spent in the last two decades cleaning up other people's disasters. 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
Le 04/03/2015 00:36, T.J. Duchene a écrit : On Tue, 03 Mar 2015 12:46:17 +0100 Didier Kryn k...@in2p3.fr wrote: Le 02/03/2015 23:43, T.J. Duchene a écrit : We just see things differently. My first question would be: is there are a justified reason NOT to use C? There is a very good reason, and I heard it was given by Kernighan and Ritchie: we assume the programmer knows what (s)he is doing. And there is a second reason: C is very tied to the hardware; it is lacking abstractions. Fair enough. If you need that level of abstraction to get the job done, so be it. It's at least a better reason that most of the others that I have heard. I would comment that levels of abstraction can be achieved in any language, and that C is just as good any other at doing so. You use abstracted libraries everyday. Although I would have to disagree that C is not tied to the hardware. That is the whole point of C. That is why C is used over assembly and why C is considered a universal language. It's usually the first one ported to any processor. Saying it is hardware dependent doesn't make sense when C, and the Linux kernel written in C are used on so many different forms of hardware. T.J., I was probably not clear enough. I dont mean architecture-dependant, but assembler-like: if ( a=b=c ) ; What does this mean? 1) let some register (call it Accumulator) be loaded with the value from location c; 2) let store Accumulator at location b; 3) let store Accumulator at location c; 4) check if Accumulator is non-zero; All this is very different of what the instruction means in ordinary language and you better keep it in mind or you will get a mess sooner or later. ++ and -- should never be used in expressions. They have been invented to generate post-increment or pre-increment with primitive compilers. GCC is perfectly able to generate them automatically. C is so error-prone that GCC has introduced warnings from the most dangerous constructs. C is semantic sugar above assembler. I do not want to reduce its merit. I have programmed in this language for 34 years. I had experiences of big programs in C and my experience is that debugging is long (and probably never ended) and evolution is a nightmare. That can be true, but it is also true of any language, or of project of substantial size: say 2,000,000+ lines of code. It really depends on how well it was designed and documented. It can be discussed A given language may do in one line the equivalent of 5 lines of C, in a self-explanatory construction. A language apropriate for a given type of problem may have well thought semantic constructs which, at the end result in calling the same functions as you do in C, but are expressed in the source code in a way which is easier to understand for the reader and easier to check by the compiler. My point is that generating efficient code is not the most important issue. The most important things are to prevent and detect programming errors and to make the source easy to read. Some people love C for just the opposite reason: it is short and cryptic and a single typo could change program's behaviour instead of causing an error. If you take all languages understood by GCC which produce executable binary (not Java bytecode), the performance of the executable code will be very close, because the code generation is the easy part and is paractically all common. The only difference, and it matters a lot, is the front-end, that is the language. wether the choice makes sense, but I don't see even why C should always be considered. Efficiency and guaranteed portability, Diedler. You can't say the same of Python, Perl, etc - because in order to use them, you have to compile them from C first. I do not deny the necessity to have C. One of the greatest merits of C is that it brings in all the others :-) Also let's not confuse high level with interpreted. Shell scripting languages are rather low-level. I don't know perl, but I think it is not much higher than C. Cheers. 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 Tue, Mar 03, 2015 at 10:07:41PM -0500, Hendrik Boom wrote: [cut] It can be discussed wether the choice makes sense, but I don't see even why C should always be considered. Efficiency and guaranteed portability, Diedler. You can't say the same of Python, Perl, etc - because in order to use them, you have to compile them from C first. Case study above, Scheme was clearly superior to C. Granted, Scheme code did get compiled to C, but what I care about here is the code the human programmers see. Without entering a religious war about languages, similar examples exist about using Erlang or Haskell instead of legacy C code. For some specific tasks (but honestly not always) these languages can outperform C implementations, in a much shorter time than that needed to get a brand-new and better-conceived C implementation of the same thing. And both Erlang and Haskell are portable on a large variety of platforms. Again, the world is not just black or white when it comes to languages (of any kind) :) 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 03/03/2015 09:07 PM, Hendrik Boom wrote: As time passed, they kept finding new uses for their scripting language. Occasionally they would realize and existing module needed major new functinoality, and it was easier to write the new version in Scheme than to modify the old. Over two years or so, they ended up replacing their C code, piece by piece, with Scheme code. In the end they had a system that was mostly written in Scheme, was more reliable, did more, ran faster, and was only about 3 lines of Scheme. When I say this, please do not think that I am making remarks against your experience or observations, but I just don't get it. I don't see how that can be the case. The version of Scheme that you mention is specifically implemented on top of C, so your remarks cannot be entirely true, nor make any sense to me at all. Scheme can't be more reliable, do more, or run faster, especially if it implemented on top of C or even converted into system object code by the very same C compiler. The entire statement is non sequitur. I will that any specific compiler, even a C compiler, can be total and utter crap, if it is badly implemented. I will also agree that individuals' programming skills can be massively lacking. It is possible that they were more skilled with Scheme than C, but that does not make Scheme superior to C by any objective standard. It was really a win for the high-level, garbage-collected language. I've used enough GC languages to know the problems that they try to solve. It's a good idea to try, really, and it is a fantastic debugging tool when testing code. But that is all it is good for. No one has ever created a fail-proof GC design. When the GC model fails, it makes fixing your code difficult, sometimes even impossible to correct without a patch for the entire runtime, not to mention you may need to recompile everything regardless after you get it. When someone can design a GC language that solves leaks and buffer overflows 100% of the time, I'll give them all the praise they deserve. Until then, the only things that GC does for you is waste memory, processor time, and force you to reboot the entire system more frequently in order to clear the exhausted resources. Have a great evening! 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 Tue, Mar 3, 2015 at 10:42 PM, T.J. Duchene t.j.duch...@gmail.com wrote: On Tue, 3 Mar 2015 07:25:23 + KatolaZ kato...@freaknet.org wrote: All computer languages are constrained to the physical nature of the processor, so the benefits of one over another are usually really nothing more than syntactic sugar. So what you're saying is that all languages are syntactic sugar over assembly? :) As a counter-argument, I would offer that you can perform any task in C, (with the extremely occasional asm block) that the processor is physically capable of, but the reverse cannot be said of other languages. Fornicate yeah! These languages might be easier to use by those allergic to to lower level ones, but the overhead and inefficiency wastes battery power. Ultimately, the time the programmers might save are spent by the potential thousand users who have wait 5 minutes for the app to run rather than 2 1/2. More and more i see it'll be more work / take longer to implement / be more complex as developer excuses to use more user-friendly languages like java (and less and less developers learning C in college so they're biased). It should be easy for the end-user, definitely; and if it can be easy for the developer as well, cool. Making something less efficient/fast/scalable/ because it's hard...? My uncalled-for €0.02 Cheers, Nuno ___ 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 Tue, 03 Mar 2015 12:46:17 +0100 Didier Kryn k...@in2p3.fr wrote: Le 02/03/2015 23:43, T.J. Duchene a écrit : We just see things differently. My first question would be: is there are a justified reason NOT to use C? There is a very good reason, and I heard it was given by Kernighan and Ritchie: we assume the programmer knows what (s)he is doing. And there is a second reason: C is very tied to the hardware; it is lacking abstractions. Fair enough. If you need that level of abstraction to get the job done, so be it. It's at least a better reason that most of the others that I have heard. I would comment that levels of abstraction can be achieved in any language, and that C is just as good any other at doing so. You use abstracted libraries everyday. Although I would have to disagree that C is not tied to the hardware. That is the whole point of C. That is why C is used over assembly and why C is considered a universal language. It's usually the first one ported to any processor. Saying it is hardware dependent doesn't make sense when C, and the Linux kernel written in C are used on so many different forms of hardware. I had experiences of big programs in C and my experience is that debugging is long (and probably never ended) and evolution is a nightmare. That can be true, but it is also true of any language, or of project of substantial size: say 2,000,000+ lines of code. It really depends on how well it was designed and documented. It can be discussed wether the choice makes sense, but I don't see even why C should always be considered. Efficiency and guaranteed portability, Diedler. You can't say the same of Python, Perl, etc - because in order to use them, you have to compile them from C first. Cheers! 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 Tue, Mar 03, 2015 at 07:25:23AM +, KatolaZ wrote: On Mon, Mar 02, 2015 at 04:35:24PM -0600, T.J. Duchene wrote: 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, Are you using expat for the C implementation, like you are for Python behind the scenes? python-stdlib requires expat, BDB 5.3, bz2, ncurses, readline, sqlite, and openssl, along with FFI, terminfo, and mime-support. However, I recognize you probably won't get C done in less than 2 hours like you do with Python. I will say that it sometimes seems like the reason leaks are a problem in C specifically is that leaks aren't considered a problem in other languages. Sure, gc-based languages eventually collect the garbage. But they seem to take a long time to do it. And they encourage a sloppy approach where acquiring a resource is not habitually matched with releasing it. And exceptions can at times be more obscure and verbose than checking return values: something three imports deep could throw an exception you never thought about, and it may propagate. Now, I've used Python a little bit, and I've used C a little bit. I won't say that Python/$scripting_language should not be used, period. But there are a lot of the features that come at costs that sometimes seem to be ignored. Thanks, Isaac Dunham ___ 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 Tue, Mar 03, 2015 at 05:36:54PM -0600, T.J. Duchene wrote: On Tue, 03 Mar 2015 12:46:17 +0100 Didier Kryn k...@in2p3.fr wrote: I had experiences of big programs in C and my experience is that debugging is long (and probably never ended) and evolution is a nightmare. That can be true, but it is also true of any language, or of project of substantial size: say 2,000,000+ lines of code. It really depends on how well it was designed and documented. I get this from a conference proceedings -- I forget which, but if pressed I can probably get a specific reference within a few days. A firm had an enterprise resource management system (at lease, that's what I think it was called) that contained about 200,000 lines of C code. Yes, that's an order of magnitude smaller thatn your example. They decided that they needed a scripting language to simplify their work. They picked Gambit Scheme for their scripting language, and they found it quite effective. Gambit Scheme is an implementation of Scheme that has a particularly intimate connection with C. It can be interpreted, but it has a compatible compiler that compiles Scheme to C. Interfacing Gambit to C is particularly easy. As time passed, they kept finding new uses for their scripting language. Occasionally they would realize and existing module needed major new functinoality, and it was easier to write the new version in Scheme than to modify the old. Over two years or so, they ended up replacing their C code, piece by piece, with Scheme code. In the end they had a system that was mostly written in Scheme, was more reliable, did more, ran faster, and was only about 3 lines of Scheme. It was really a win for the high-level, garbage-collected language. Now I'll admit that not all problems are like that. But I suspect that many are. It can be discussed wether the choice makes sense, but I don't see even why C should always be considered. Efficiency and guaranteed portability, Diedler. You can't say the same of Python, Perl, etc - because in order to use them, you have to compile them from C first. Case study above, Scheme was clearly superior to C. Granted, Scheme code did get compiled to C, but what I care about here is the code the human programmers see. -- 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 23:43, T.J. Duchene a écrit : We just see things differently. My first question would be: is there are a justified reason NOT to use C? There is a very good reason, and I heard it was given by Kernighan and Ritchie: we assume the programmer knows what (s)he is doing. And there is a second reason: C is very tied to the hardware; it is lacking abstractions. The sentence can be compared to Ada's design rationale: we assume the programmer is a human being (meaning (s)he persistently makes mistakes). Maybe KR never wrote that sentence, but I like it because it fits very well with the nature of the C language. unsigned u = -2; /* example */ I am very admirative of how the Linux kernel is efficient and safe, but everybody knows that this is achieved by hard work of some of the best C programmers in the world. This is THE exception. I had experiences of big programs in C and my experience is that debugging is long (and probably never ended) and evolution is a nightmare. For me, the question is rather why choose a given language out of all available languages? And the reason is generally because the programmer feels more comfortable with one. It can be discussed wether the choice makes sense, but I don't see even why C should always be considered. 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
Le 03/03/2015 01:08, T.J. Duchene a écrit : 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. Alas no! There's the F. shared libraries. It works only if you link statically, which is discouraged by the glibc just because Ulrich Drepper does not like it. 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 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 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 little
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
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, that's just fine by me. =) Have a great day! t.j.
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 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: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
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
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 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] [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 kato...@freaknet.org 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 kato...@freaknet.org 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 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 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
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] [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 Sun, 2015-03-01 at 21:12 +0100, Philip Lacroix wrote: As other members have already pointed out, this is not a fair comparison. Perhaps. The reasons I made the comparison are: a) All of them have a dependency chain so interwoven and complex that they become non-trivial to remove. You literally cannot have a Debian/Devuan system without things like Perl or Python installed. b) The software written in either language have complex module dependency chains. Install something like MailScanner, and you will install a dozen Perl modules as well as a requirement. c) In both languages, modules are usually something of a black art and notorious for being unreliable at unexpected times. 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. Systemd comes on the scene. Like everything else, it naturally has its good and bad points. Soon it starts following a repeating pattern: a) Soon Linux requires it, and it is non-trivial to be rid of it. b) Modules are written in such a way that you must have the core or a shim to use the system. Then they are incorporated into yet more software, and it snowballs. (Sound familiar?) c) The systemd modules impact system performance, and are less than reliable. Again like the the above, the real QA is simply not there. So yes, I do feel the comparison is somewhat valid. My concern however is not a perfect symmetry, but rather the design philosophy behind them. Over the years I've been a programmer the level of abstraction has increased dramatically. More and more complex layers of dependencies are placed one on top of the other. It's the order of the day, and to what end? Call me a minimalist if you like, but as Scotty used to say: The more you over-think the plumbing, the easier it is to stop up the drain. Software performance and reliability has actually decreased in spite of the fact that your machines are far, far more powerful than the old 8086 I used to spend my days on. You are, of course, welcome to disagree and even tell me to stuff it if you wish. Maybe I just come from another time, but I would characterize things like Perl, Python, and Systemd as the push for more and more abstraction that is detrimental to computer science in general. Packaging is, in the end, just a practical way to manage compiled software on your system. On the other hand, what a given software does, and how that software is tied to other software, is inherently independent from which package management system is being used. If software A needs software B because its developer decided to rely on software B, then it doesn't matter whether the downstream packager decides to put B as a dependency or not. However, if he doesn't, then software A most probably won't work as intended, if it'll work at all. I'm not advocating abandoning the model entirely, rather that some of the constraints could be removed and that a more robust model could be created using version management software. I suggested that init files should be separated for example. Init files seldom change between versions. Sometimes they do, certainly - but the majority of the time they are virtually identical. Why repackage the same files over and over? It wastes repo space and user bandwidth every single time an update is issued. Furthermore, if Debian had had a policy of keeping init files apart from binary files, I doubt Devuan would have as much work as they eventually will when Debian goes all in on systemd. Only the init setups, and binaries linked to systemd would require systemd in their chain. At least, that's the way I see it. Feel welcome to disagree, it was just a brainstorm I was tossing about after considering that it was actually the System 5 maintenance resolution that crippled Debian, not systemd itself. The lack of any promise for System 5 is why we are here. Cheers! 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 Sun, 1 Mar 2015, T.J. Duchene wrote: On Sun, 2015-03-01 at 21:12 +0100, Philip Lacroix wrote: As other members have already pointed out, this is not a fair comparison. Perhaps. The reasons I made the comparison are: a) All of them have a dependency chain so interwoven and complex that they become non-trivial to remove. You literally cannot have a Debian/Devuan system without things like Perl or Python installed. The perl-base package pre-depends on libc6 and dpkg. And nothing else. The python2.7-minimal package depends on libpython2.7-minimal and zlib1g and pre-depends on libc6. The libpython2.7-minimal package has no depends or pre-depends. This does not look interwoven and complex to me. You need a C library, you need dpkg, and you need zlib, all of which are perfectly reasonable things to expect from a bare-bones Linux system. b) The software written in either language have complex module dependency chains. Install something like MailScanner, and you will install a dozen Perl modules as well as a requirement. 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. 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? 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? ___ 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 Sat, Feb 28, 2015 at 06:11:42PM -0600, Nate Bargmann wrote: * On 2015 28 Feb 17:07 -0600, T.J. Duchene wrote: As for systemd having tentacles, there is certainly truth to that, but then the same argument could be said of Python or Perl. Both are rooted so far into standard distributions that it is hard to extract them. With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. They are tools a programmer uses to solve a problem which parallels your point that systemd is a tool for distributions, but yet it is seeking to impose a policy many of us dislike, especially going forward. Debian users are a bit insulated at the moment as the freeze is keeping systemd at a given version. Its tentacles extend even further in later versions, AIUI. The way Perl and Python are different from systemd is that they are not exclusionary -- using them for one package doesn't prevent using other tools in other packages. -- 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
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. 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. 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. 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. 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. It hardly matters though. I said my piece. You're certainly welcome to read it however you like. I said what was on my mind, and you are free to make your own judgements. I'm not offended in any case. So you don't agree. Good for you! =) That means that you gave it some thought. 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 12:16 AM, T.J. Duchene wrote: I was not referring to all the software that depends on them when using Debian/Devuan. *I was referring to all the software that depends on them when using Debian/Devuan. * Bad editing on my part. Mea Culpa. ___ 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 Sun, Mar 01, 2015 at 01:53:11AM -0500, Gravis wrote: Having [perl and python] doesn't cost much, IMO. this is true however, you only need a single deep-seeded flaw to exploit an entire system when it comes to scripting. for further reading, see bash. This is true of any library you might use, whether it's a scripting language or not. Such tools tend to get more reliable the more they are used, because more bugs are found and fixed. -- 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
On Sun, 1 Mar 2015 09:01:58 -0500 Hendrik Boom hend...@topoi.pooq.com wrote: On Sat, Feb 28, 2015 at 06:11:42PM -0600, Nate Bargmann wrote: * On 2015 28 Feb 17:07 -0600, T.J. Duchene wrote: As for systemd having tentacles, there is certainly truth to that, but then the same argument could be said of Python or Perl. Both are rooted so far into standard distributions that it is hard to extract them. With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. They are tools a programmer uses to solve a problem which parallels your point that systemd is a tool for distributions, but yet it is seeking to impose a policy many of us dislike, especially going forward. Debian users are a bit insulated at the moment as the freeze is keeping systemd at a given version. Its tentacles extend even further in later versions, AIUI. The way Perl and Python are different from systemd is that they are not exclusionary -- using them for one package doesn't prevent using other tools in other packages. True, and in addition, they've both been pretty much assumed to be installed on every distro for the last decade. 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
Am 01.03.2015 00:04 schrieb T.J. Duchene: As for systemd having tentacles, there is certainly truth to that, but then the same argument could be said of Python or Perl. Both are rooted so far into standard distributions that it is hard to extract them. As other members have already pointed out, this is not a fair comparison. Ultimately, the whole problem revolves around the idea of packaging. Personally, I've come to believe that the existing idea of package management is more damaging to Linux than systemd itself. If the Debian packaging system separated the actual init files from binary package files, then majority of developers making Jesse packages that assume systemd rather than System 5 would be non-issue. I'm not sure that I agree with this. Packaging is, in the end, just a practical way to manage compiled software on your system. On the other hand, what a given software does, and how that software is tied to other software, is inherently independent from which package management system is being used. If software A needs software B because its developer decided to rely on software B, then it doesn't matter whether the downstream packager decides to put B as a dependency or not. However, if he doesn't, then software A most probably won't work as intended, if it'll work at all. Of course packaging, especially when automatic dependency resolution is implemented, will introduce loads of possible decisions that can be made by downstream packagers, but this is a completely different story, let alone the so-called tasks, which I admit having always skipped while using Debian: in fact I wanted to decide by myself which were the defaults I needed. That being said, the Grand Unifying Init System's attempt to hijack a large part of the free software ecosystem, by imposing itself as a hard dependency, is technically independent from downstream packaging decisions, even if it does influence those decisions. I guess that far from focusing on subjective topics, DeVuan is forking DeBian itself right now, while encouraging objective and balanced discussion, which is welcome and a pleasure to read. Fair enough, Philip. Who am I to say it does not have entertainment value? Not only entertainment value: educational and *ethical* value as well. As a person who has written C code and used Unixes for about 20+ years, I see some technical benefit in systemd's approach. Just because systemd itself has design flaws does not mean the entire concept is bad. The fact that I come right out and say so, even if it just happens to go against the majority sensibility is: with blunt honestly, not my problem. No one ever said that its entire concept is bad. Moreover, I think it is kind of useless to insist with this here, since Devuan is intentionally, consciously and rationally avoiding systemd, no matter what its technical merits are. I'm not really looking for a debate on the topic, because in the grand scheme of things my opinion does not amount to much, really. Nor should it. You should always make up your own mind. Of course. If you'd rather not hear it, I can certainly go elsewhere or refrain from posting, but I personally do not believe that Devuan needs yes men (or yes-women). Well, the decision is completely up to you. I am a guest on this list, and I'm a peaceful fellow, hence it is not my goal, nor my right, to send anyone away, whatever opinions they have. On the other hand, as others have pointed out, there are plenty of pro/anti systemd debates on the Web already, so it makes no sense to replicate them here, a systemd-free project by definition. This one seems to have been inspired by Microsoft's ancient anti-Linux FUD marketing campaign - you know, the one with a long-proboscized monster-penguin. Not at all. It is simply a comment on the collective nature of Linux. Sometimes design by committee is not the best approach. That's simply life. That I call Linux a Linux is a mean-spirited, ugly camel with the number of humps chosen by committee but endearing at the same time is nothing more than a recognition that it has flaws. There are precisely zero perfect software projects in the world. Having had this much time in the field, I simply have no illusions about it is all, and I feel free to say so. Agreed, but one can find drawbacks in every approach, and again, it makes little sense to reiterate this here, since it is a well known factor which can potentially affect just about every situation where humans interact. Most of all, it doesn't seem to be a problem affecting Devuan very much. I'm sorry if that bothers you, but it hardly seems a secret to me. It doesn't bother me, I just find it pretty useless and redundant, and not much constructive: I guess we already know that the Open Source community is full of a**holes, etc. etc. Have a great day, Philip! =) Have a great day too, t.j. Philip
Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Sat, 2015-02-28 at 21:03 +0100, Philip Lacroix wrote: I wouldn't call personality clash the case of a user having specific problems with systemd's networking tentacles on Debian Jessie, don't you think? Actually, yes I would call it a personality problem, but only because I have seen them before. No offense. As for systemd having tentacles, there is certainly truth to that, but then the same argument could be said of Python or Perl. Both are rooted so far into standard distributions that it is hard to extract them. Ultimately, the whole problem revolves around the idea of packaging. Personally, I've come to believe that the existing idea of package management is more damaging to Linux than systemd itself. If the Debian packaging system separated the actual init files from binary package files, then majority of developers making Jesse packages that assume systemd rather than System 5 would be non-issue. Anyway, I guess that far from focusing on subjective topics, DeVuan is forking DeBian itself right now, while encouraging objective and balanced discussion, which is welcome and a pleasure to read. *Nod* Fair enough, Philip. Who am I to say it does not have entertainment value? Quite frankly, it sounds like you're actually trying to *pose* as a Devuan supporter, which you seem not to be. Rest assured that I wouldn't be here if I didn't think Devuan was worthwhile. As a person who has written C code and used Unixes for about 20+ years, I see some technical benefit in systemd's approach. Just because systemd itself has design flaws does not mean the entire concept is bad. The fact that I come right out and say so, even if it just happens to go against the majority sensibility is: with blunt honestly, not my problem. I'm not really looking for a debate on the topic, because in the grand scheme of things my opinion does not amount to much, really. Nor should it. You should always make up your own mind. If you'd rather not hear it, I can certainly go elsewhere or refrain from posting, but I personally do not believe that Devuan needs yes men (or yes-women). The reality is that Linux is a mean-spirited, ugly camel with the number of humps chosen by committee. For all of that, it is rather endearing - because you can make of it what you will. No one can charge you in court or judge less of your character for doing your own thing. This one seems to have been inspired by Microsoft's ancient anti-Linux FUD marketing campaign - you know, the one with a long-proboscized monster-penguin. Not at all. It is simply a comment on the collective nature of Linux. Sometimes design by committee is not the best approach. That's simply life. That I call Linux a Linux is a mean-spirited, ugly camel with the number of humps chosen by committee but endearing at the same time is nothing more than a recognition that it has flaws. There are precisely zero perfect software projects in the world. Having had this much time in the field, I simply have no illusions about it is all, and I feel free to say so. I'm sorry if that bothers you, but it hardly seems a secret to me. Have a great day, Philip! =) 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 2015 28 Feb 17:07 -0600, T.J. Duchene wrote: As for systemd having tentacles, there is certainly truth to that, but then the same argument could be said of Python or Perl. Both are rooted so far into standard distributions that it is hard to extract them. With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. They are tools a programmer uses to solve a problem which parallels your point that systemd is a tool for distributions, but yet it is seeking to impose a policy many of us dislike, especially going forward. Debian users are a bit insulated at the moment as the freeze is keeping systemd at a given version. Its tentacles extend even further in later versions, AIUI. Other tools we're familiar with also dictate policy at some level such as dpkg and apt, however, the authors of those tools don't start throwing around the term haters whenever someone sets out to compile from source outside of their policy. Do you see the difference? systemd strongly reflects the personality of its developers. Unfortunately, that doesn't make it unique, but it's the first time I recall a lead developer being so outspoken since the CDR tools guy was routed around by Debian and others. Personally, the existence of systemd is fine if that is what an admin or user or distribution finds useful. Debian made its choice and after looking at it for a while I don't want to continue down that road. That doesn't make me a hater, I prefer the term discerning. - Nate -- The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true. Ham radio, Linux, bikes, and more: http://www.n0nb.us ___ 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
Am 27.02.2015 21:18 schrieb T.J. Duchene: With respect to all, I think that a measure of objectivity is called for here. I think that because personality clashes that Debian's entire systemd discussion has lost any sense of reality long ago. I wouldn't call personality clash the case of a user having specific problems with systemd's networking tentacles on Debian Jessie, don't you think? Anyway, I guess that far from focusing on subjective topics, DeVuan is forking DeBian itself right now, while encouraging objective and balanced discussion, which is welcome and a pleasure to read. With no offense or judgment intended, I'd rather not see Debian's mud at our door. The reason we left was to get away from it. Devuan does not need to justify its own existence. Debian's mud at our door? The reason we left? With all due respect and no judgement intended, your sudden use of the royal We on this list is quite surprising, especially since about three weeks ago you wrote the following comments, which strikingly resemble to what can be read on Poettering's blog, which is being copypasted around the web by many well-disguised Yes-Men: Funny thing. I hear a lot of complaining about systemd, and yes, i think some of it is justified, but consider this... Rather than joining the project and steering it in another direction, or creating patches to fix what you do not like, everyone is just standing about complaining. (...) The reality is that no matter what anyone does, systemd is here to stay (...) There is no escaping this fact of life. Linux as an OS is developed in a hodgepodge of distributions. The reason systemd has found such wide adoption is that it simplifies their work. Quite frankly, it sounds like you're actually trying to *pose* as a Devuan supporter, which you seem not to be. The reality is that Linux is a mean-spirited, ugly camel with the number of humps chosen by committee. For all of that, it is rather endearing - because you can make of it what you will. No one can charge you in court or judge less of your character for doing your own thing. This one seems to have been inspired by Microsoft's ancient anti-Linux FUD marketing campaign - you know, the one with a long-proboscized monster-penguin. However, let's paraphrase it: of course Linux is free software released under the GPL and similar licenses, therefore you can make of it what you will... unless somebody manages to nail it down through some subtle and nasty agenda which makes said licenses useless. I've had Debian, RedHat, and just about every major distribution grace my system at some point. With every single one of them, without exception, has had issues of some kind or another. Some of which were major showstoppers. Some didn't even boot, others were so poorly assembled that you'd think the packagers were drunken monkeys. Unfortunately I cannot brag such a catastrophic experience with Linux distributions myself, but that's probably my fault. Anyway, your comment sounds like yet another iteration of the Linux is broken mantra, hence I encourage you to jump on (or return to) the Grand Unifying Init System bandwagon. All of this started long before systemd was ever created, and will certainly be around long after systemd is forgotten. Yeah. However, this is (again) just another way to say That's the way it is, or So goes the world, while dismissing specific problems by pushing them inside the foggy and much undetermined concept of life. Philip ___ 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 Sun, Mar 01, 2015 at 12:05:32AM -0500, Gravis wrote: My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them Having them don't cost much, IMO. A lot of the Debian infrastructure is written in perl. In Gobo Linux, the system administration software is written in shell. Utility for administrating Nix are written in Nix language. this is actually something i'm looking into fixing. my preference would be to make a standard POSIX base to build upon. the LSB is a bad joke. As a basis for building Linux distributions? You may look into Automated Linux from Scratch http://www.linuxfromscratch.org/alfs/ cheers --Gravis On Sat, Feb 28, 2015 at 11:49 PM, T.J. Duchene t.j.duch...@gmail.com wrote: On Sat, 2015-02-28 at 18:11 -0600, Nate Bargmann wrote: With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. I would not consider C in that group, as the system actually requires the C library for the OS to function on the most basic level, not to mention that the kernel, Perl and Python are actually written in C. My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them, without pulling a DIY. Linux as a platform does not require them to function. What makes it relevant to the conversation is that it is all about attitude. They are enthusiastically endorsed by communities that refuse to acknowledge that either can be as much of a hindrance as a help in many cases. For example, Python as a programming language is designed specifically to dictate how you do things, i.e. Zen of Python: There should be one-- and preferably only one --obvious way to do it. Sometimes Linux can be its own worst enemy. Other tools we're familiar with also dictate policy at some level such as dpkg and apt, however, the authors of those tools don't start throwing around the term haters whenever someone sets out to compile from source outside of their policy. Do you see the difference? There is some truth to that, but you can revisit that virtually anywhere there are fanboys/fangirls. The fact that few authors like LP can use the term haters to divert attention from the real issues, and then get a free pass just shows how easily the issue has polarized others and how easily the sheeple are manipulated into going along. t.j. ___ 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 -- Joel Roth ___ 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 Sat, 2015-02-28 at 18:11 -0600, Nate Bargmann wrote: With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. I would not consider C in that group, as the system actually requires the C library for the OS to function on the most basic level, not to mention that the kernel, Perl and Python are actually written in C. My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them, without pulling a DIY. Linux as a platform does not require them to function. What makes it relevant to the conversation is that it is all about attitude. They are enthusiastically endorsed by communities that refuse to acknowledge that either can be as much of a hindrance as a help in many cases. For example, Python as a programming language is designed specifically to dictate how you do things, i.e. Zen of Python: There should be one-- and preferably only one --obvious way to do it. Sometimes Linux can be its own worst enemy. Other tools we're familiar with also dictate policy at some level such as dpkg and apt, however, the authors of those tools don't start throwing around the term haters whenever someone sets out to compile from source outside of their policy. Do you see the difference? There is some truth to that, but you can revisit that virtually anywhere there are fanboys/fangirls. The fact that few authors like LP can use the term haters to divert attention from the real issues, and then get a free pass just shows how easily the issue has polarized others and how easily the sheeple are manipulated into going along. 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
My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them this is actually something i'm looking into fixing. my preference would be to make a standard POSIX base to build upon. the LSB is a bad joke. --Gravis On Sat, Feb 28, 2015 at 11:49 PM, T.J. Duchene t.j.duch...@gmail.com wrote: On Sat, 2015-02-28 at 18:11 -0600, Nate Bargmann wrote: With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. I would not consider C in that group, as the system actually requires the C library for the OS to function on the most basic level, not to mention that the kernel, Perl and Python are actually written in C. My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them, without pulling a DIY. Linux as a platform does not require them to function. What makes it relevant to the conversation is that it is all about attitude. They are enthusiastically endorsed by communities that refuse to acknowledge that either can be as much of a hindrance as a help in many cases. For example, Python as a programming language is designed specifically to dictate how you do things, i.e. Zen of Python: There should be one-- and preferably only one --obvious way to do it. Sometimes Linux can be its own worst enemy. Other tools we're familiar with also dictate policy at some level such as dpkg and apt, however, the authors of those tools don't start throwing around the term haters whenever someone sets out to compile from source outside of their policy. Do you see the difference? There is some truth to that, but you can revisit that virtually anywhere there are fanboys/fangirls. The fact that few authors like LP can use the term haters to divert attention from the real issues, and then get a free pass just shows how easily the issue has polarized others and how easily the sheeple are manipulated into going along. t.j. ___ 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 Sat, Feb 28, 2015 at 08:18:59PM -1000, Joel Roth wrote: On Sun, Mar 01, 2015 at 12:05:32AM -0500, Gravis wrote: My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them Having them don't cost much, IMO. A lot of the Debian infrastructure is written in perl. In Gobo Linux, the system administration software is written in shell. Utility for administrating Nix are written in Nix language. this is actually something i'm looking into fixing. my preference would be to make a standard POSIX base to build upon. the LSB is a bad joke. As a basis for building Linux distributions? You may look into Automated Linux from Scratch http://www.linuxfromscratch.org/alfs/ And interesting to find that the LFS books exist in regular and systemd flavors. http://wiki.linuxfromscratch.org/alfs/wiki/SupportedBooks The jalfs software hasn't been undated changed since 2009, however the LFS books are current. cheers --Gravis On Sat, Feb 28, 2015 at 11:49 PM, T.J. Duchene t.j.duch...@gmail.com wrote: On Sat, 2015-02-28 at 18:11 -0600, Nate Bargmann wrote: With all respect, T.J., those are merely programming languages--shell, C and C++ are also hard to extract--but none are trying to dictate policy. I would not consider C in that group, as the system actually requires the C library for the OS to function on the most basic level, not to mention that the kernel, Perl and Python are actually written in C. My point is that Perl and Python as system software are forced on you in a Linux distribution as a requirement in much the same way that systemd is. You can't get rid of them, without pulling a DIY. Linux as a platform does not require them to function. What makes it relevant to the conversation is that it is all about attitude. They are enthusiastically endorsed by communities that refuse to acknowledge that either can be as much of a hindrance as a help in many cases. For example, Python as a programming language is designed specifically to dictate how you do things, i.e. Zen of Python: There should be one-- and preferably only one --obvious way to do it. Sometimes Linux can be its own worst enemy. Other tools we're familiar with also dictate policy at some level such as dpkg and apt, however, the authors of those tools don't start throwing around the term haters whenever someone sets out to compile from source outside of their policy. Do you see the difference? There is some truth to that, but you can revisit that virtually anywhere there are fanboys/fangirls. The fact that few authors like LP can use the term haters to divert attention from the real issues, and then get a free pass just shows how easily the issue has polarized others and how easily the sheeple are manipulated into going along. t.j. ___ 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 -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ 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
Lol! I recently happened to be researching the different soundsystem architectures, after incinerating pulseaudio on my laptop/Wheezy and then having different problems, and found -- https://wiki.debian.org/Sound What struck me of particular interest were the three diagrams of how alsa/jack/pulseaudio perceive the sound architecture. I couldn't help but think that systemd very likely has the same structure. The mother, may I?/None shall pass/TRON MCP structure. Developers often hang to a general pattern of designing things; I cant see why the designer behind pulseaudio would be different. Best argument against systemd I've seen to date. SWS On Feb 27, 2015 11:45 PM, Steve Litt sl...@troubleshooters.com wrote: On Fri, 27 Feb 2015 14:18:15 -0600 T.J. Duchene t.j.duch...@gmail.com wrote: With respect to all, I think that a measure of objectivity is called for here. I think that because personality clashes that Debian's entire systemd discussion has lost any sense of reality long ago. You know, T.J., I might just agree with you, *if* you can show me a block diagram of the systemd ecosystem, *complete with interaction lines as well as functional blocks*. You know, like this: http://troubleshooters.com/lpm/201202/images/email_arch_personal.png Or these: http://troubleshooters.com/lpm/200803/images/server_app.png http://troubleshooters.com/lpm/200803/images/client_app.png Or these: http://www.troubleshooters.com/linux/djbdns/images/mm_process_overview.png http://www.troubleshooters.com/linux/djbdns/images/mm_daemontools.png http://www.troubleshooters.com/linux/djbdns/images/mm_minimal_service.png http://www.troubleshooters.com/linux/djbdns/images/mm_dnscache_block_diagram.png http://www.troubleshooters.com/linux/djbdns/images/mm_tinydns_block_diagram.png Or this: http://www.troubleshooters.com/linux/nullmailer/images/nullmailer_mm.png But not the following, because it's boxes with no lines: http://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Systemd_components.svg/440px-Systemd_components.svg.png Nor this, because it's obviously incomplete as a representation of the systemd ecosphere: http://upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg/440px-Linux_kernel_unified_hierarchy_cgroups_and_systemd.svg.png Bottom line is this: If you make a modular system with thin interfaces and sane components, somebody will make a block diagram representing it, accurately, in its entirety. It could be argued that the email, sockets, and djb software systems I diagrammed were much simpler than systemd. Fair enough, but I'm one guy doing this stuff in my spare time, not six guys getting paid full time by Red Hat. I'm sure one of the geniuses Red Hat hired could have diagrammed system accurately and completely. Heck, I often do that *before* I write software, just so the system turns out architecturally sound. Let's see the block diagram. Prove systemd doesn't have grave architectural problems. 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 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[Dng] [OT] Debian problems with Jesse - was simple backgrounds
On Fri, 2015-02-27 at 18:13 +, KatolaZ wrote: On Fri, Feb 27, 2015 at 01:56:56PM +, Matthew Melton wrote: [cut] Just to support my point, Debian has a great logo, but this is what is currently happening to the users of Jessie, thanks to the systemd-nonsense: https://lists.debian.org/debian-user/2015/02/msg00013.html Well, I still find it hard to believe that a modern Unix OS might be stuck at boot because I forgot to connect an ethernet cable... This is the essence of the systemd-nonsense. In that case it was just a laptop, but can you imagine something similar happening on a production server? Who is going to pay for the downtime that these little glitches are going to cause? How much should systemd damage With respect to all, I think that a measure of objectivity is called for here. I think that because personality clashes that Debian's entire systemd discussion has lost any sense of reality long ago. With no offense or judgment intended, I'd rather not see Debian's mud at our door. The reason we left was to get away from it. Devuan does not need to justify its own existence. The reality is that Linux is a mean-spirited, ugly camel with the number of humps chosen by committee. For all of that, it is rather endearing - because you can make of it what you will. No one can charge you in court or judge less of your character for doing your own thing. I've had Debian, RedHat, and just about every major distribution grace my system at some point. With every single one of them, without exception, has had issues of some kind or another. Some of which were major showstoppers. Some didn't even boot, others were so poorly assembled that you'd think the packagers were drunken monkeys. All of this started long before systemd was ever created, and will certainly be around long after systemd is forgotten. t.j. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
