Just felt a small vibration in the general area of my stomach, which I confirmed to be a massive turd waiting for departure, followed by a much more violent pressure release 2.7 minutes later on the crapper.
That being said, I think it wouldn't hurt making it implementation-defined behaviour instead (which isn't much better from a portability point of view, but at least requires implementations to document their choice)
I'm not sure if one could think of it in terms of 'feature' or 'bug', but if anything, i'd go for feature. There are at least 3 major ways to represent negative numbers (1s complement, 2s complement, sign-magnitude), and overflowing the representation of INT_MAX doesn't necessarily give anything close to INT_MIN (e.g. sign-magnitude would roll over to negative zero).
So in order to be as widely adaptable as possible, C can't assume a particular way of how negative numbers are represented, so defining the consequences of overflowing is intentionally omitted
That's probably because people want it, and web hosts would be quite a failure when not providing what the customer wants. Again, that doesn't make the language less shitty.
The fact that you can go out of your way and produce "good" PHP code doesn't really make the language less shitty.
My favorite analogy:
Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
In C, overflowing a signed integer type is undefined behaviour; unsigned type wrap around to zero in a defined manner. Of course, either is often undesired, but the latter at least doesn't allow basically anything to happen.
If you did the math, you don't need excess space. If you need excess space, you're just shifting the day of failure into the future. Yes, perhaps far enough, but still.
I'm not trying to convince the users to use BSD (hilarious thought, like the users a) had a say in it or b) could tell the difference anyway), neither am i trying to convince you to use BSD. Why do you keep making up stuff like this?
Easy escape of all others point?
I don't feel like wasting more time with you by deciphering your incoherent gibberish and giving long-ish answers just to find you aren't reading them anyway.
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
Try reading instead of gibbering like a drooling idiot. That was not about supporting a linux server, but supporting a desktop GUI-only installation base for clueless users, you clueless twat.
Yeah that's odd. If you add -w to diff, then it reduces to "only" 9 megs. If you look into the diff, you see it's a massive style commit. Removing redundant braces, breaking long lines, indenting preprocessor directives.
They really should have mentioned it in the changelog. Plus, *adjusts tinfoil hat*, that's exactly the kind of commit where a deliberate change is as easily inserted as it is overlooked...
The fact that a sysadmin use[s] a shell command interpreter d[oes] not imply that the command[s] he call[s] are shell script[s].
So your idea of a sysadmin is someone who keeps typing the same commands over and over again, every day or week, rather than automating them in a script? Good grief.
I think that I have show[n] enough pro[of] that shell scripts are not as essential outside of system V init as you [] claim.
So you don't understand what a proof is, besides not having a faint clue of real-world systems administration. Duly noted.
Now, this do[es]n't prevent anyone [fr]o[m] us[ing] a shell to get a CLI [lol what] and to write some scripts if [they] like to do so. You seem to forget that the maintainers['] decision to switch to systemd is not to remove power [fr]o[m] the users, but to make the maintainers['] work [] eas[ier]
Ah, okay, maybe that's the issue then. Because so far i had assumed systemd would provide immediate benefits to the users, because that's kind of what a million pimply-faced systemd fanboys claim.
s[o] I don't understand how stressed you are about the systemd architecture.
I thought i had made that clear. Anyway, the recent 3-4 comments were more about shell scripting in general than about systemd in particular.
About the comparison between Linux and BSD kernel, you still fail[] to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes.
You clearly are a complete idiot and not paying attention, if you would actually follow this moronic discussion you'd have ran across:
I'd love to have them run *BSDs, but since they're even less meant for the 'GUI-only desktop' use case, the amount of work required to support that would require more than four admins (good ones of which are hard enough to find for linux already).
A reboot for a upgrade will not affect [???] the availability because it only affect[s] the users for a minute or so
Thanks for another demonstration of how all your sysadmin "knowledge" is purely theoretical and pulled out of your ass. Read this.
So I think we can at least agree that the upgrade on Linux is no[t] affecting your operation more that your BSD boxes.
That's only because the Linux server sits around idle unless it's 4am or an office machine is reinstalling.
And if you can really crash a[n] up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause[s] the crash.
I have already realized you're not paying attention, or mentally incapable of doing so, that was in a timespan of at least 5 years. And when talking about "Linux machines i've seen crashing", I'm not specifically referring to that one particular single FAI server. That's not to say that it hadn't had its share of problems, but the bulkload of Linux machines i've seen panicing happened in private contexts. I'm still not sure if you're seriously trying to say that Linux would be free of problems. But you're a troll or a raging zealot, so whatever.
I (obviously) know that p age, and had you cared to actually take a look at it, most of those SAs are userspace related, and we have evaluated every kernel-related one for whether it affects us or not. The user-accessible ssh login gateway was affected to some, and subsequently got rebooted. Why am i explaining this to an armchair sysadmin?
Restarting services take[s] less time than rebooting (especially with systemd), this is less risky on a remote machine, and
I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
And I still call bullshit because scripts are every admin's (and that doesn't even stop with systemd) best and most valuable tool. I don't presume you're seriously going to claim that even admins could completely forgo of the shell? Or would want to do that in the first place? (Hint: automation). If a sys- and network admin entirely using GUIs to do their job is what you imagine, then you're so far away from reality, it's not even funny anymore...
I mentioned busybox to show that binary commands [are] enough to admin a box
And what do you think is the execution environment for literally every single of those tools? Seriously if you were even slower, you'd go backwards.
I have see[n] a lot of Linux boxes with load[s] like the one you describe[d] on your BSD box[es], this is not impressive at all.
That wasn't mean to impress, i was merely responding to your claim about unfair comparisons. Nice try, but it would help if you would consider the parts you reply to in their actual context, instead of trying to create and tear down straw men like this.
Now, did your Linux kernel really crash[]?
Yes, I've seen uncountable instances of linux panicing.
I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
I didn't say the reboots required by updates were a stability problem; they are an availability problem, however.
About the libc update, you might find [it] simple[r] to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade[s], [what] [do] you do with your BSD boxes[]? Or [is] the BSD libc [] so perfect that no upgrades [are] required[]? Hint: https://www.freebsd.org/securi...
Hint: It's not FreeBSD, and Hint: if the BSD servers receive a libc update that fixes a security issue we're affected by, then the server gets rebooted. Not that i hadn't already said that in the post before.
You call me ridicul[ous], but I largely prefer restarting some services
if it's a libc fix, "some" services will not cut it.
It's a choice, and I will not call you ridicul[ous] for your own choice.
Well if you choose to go for a reboot-less libc security upgrade just to keep uptime (yet losing availability), then i'd actually ridicule you for that, because it'd be a moronic waste of time. If you get paid by the hour, maybe.
If you are so conservative to reboot each box[] as soon as a libc or kernel upgrade [appears], then I wonder how your BSD boxes could have uptime[s] a "few orders of magnitude less shitty".
See above.
aerospace, or railway, or automotive, or civil engineering standards
So, let's assume you're designing some aerospace-grade embedded system, linux based no less. Would you make it use systemd? Why not?
But I would like to rem[ind] you th[at] this discussion is about the fact [t]hat Ubuntu has released [their] first version with systemd:-)
If we talk about the admin work, it's not fair to count/usr/*. On a typical Debian Jessie I have:
file/bin/*/sbin/* | egrep ELF | wc -l
233
file/bin/*/sbin/* | egrep script | wc -l
36
I don't understand why it wouldn't be fair to count/usr. There's no clean separation between what goes into/*bin and what goes into/usr/*bin in Linux; you find many elementary programs in/usr for twisted, for historical and for essentially no particular reason. Even having/usr be a separate partition is not recommended anymore, unless you're into building your own initrd (which non-admins wouldn't ever do, by (your) definition).
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter.
Wow, hold on. Realize what you're saying, please. You're not exactly going to click on the programs provided by busybox in a GUI, are you? Or most of the other programs for that matter. It's the very point of busybox to provide a set of programs which/only/ make sense in a shell, and by extension, are get used in scripts. Why provide busybox at all, otherwise??
NetworkManager [...] is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI.
Okay, I wasn't aware of that split. If it's indeed a clean separation, then it's not so bad, indeed.
I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
*vomits*
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed.
Not sure how a GUI application is related here, FAI clearly is not a GUI and the Linux server obviously doesn't run X11.
But you're right, it was an unfair comparison, let's see:
The Linux server run: a) PXE/thttpd for network booting, b) nightly cronjobs to do maintenance on the desktops, c) a Debian repository.
The BSD servers are: fileserver, redundant mailservers (smtp(s)/pop3(s)/imap(s)), redundant nameservers, DHCP, httpd, sshd, redundant LDAP, print server, a captive portal for one of three wireless networks, firewalls, NAT gateways, svn server, you-name-it. Probably a few other common services that currently don't come to mind. Essentially a full-fledged, rather traditional production network, with amazing availability. (You know, the kind of thing people mistakenly believe "the cloud" to provide;)). So, unfair a comparison indeed, but not really the way you meant it, i guess.
You don't have to reboot to update the libc
Don't be ridiculous. Every userspace process directly or indirectly uses libc, so yes, instead of rebooting you could indeed manually stop all the services and kill all remaining tasks until the system is essentially single-user, and then get all the services going again. But no, only a complete idiot would actually do that. For all practical purposes, it would equal a reboot (and underlines my point of high degrees of hand-holding)
and you are free to decide if you like to update you kernel depending on the risk that apply to your situation.
Sure, but there's only one policy here that makes sense, and it equally applies to all
Slashdot Mirror
Just felt a small vibration in the general area of my stomach, which I confirmed to be a massive turd waiting for departure, followed by a much more violent pressure release 2.7 minutes later on the crapper.
That's not what tautology means.
Quiet, audience!
You win over white-black-black-brown Internets.
That being said, I think it wouldn't hurt making it implementation-defined behaviour instead (which isn't much better from a portability point of view, but at least requires implementations to document their choice)
I'm not sure if one could think of it in terms of 'feature' or 'bug', but if anything, i'd go for feature. There are at least 3 major ways to represent negative numbers (1s complement, 2s complement, sign-magnitude), and overflowing the representation of INT_MAX doesn't necessarily give anything close to INT_MIN (e.g. sign-magnitude would roll over to negative zero).
So in order to be as widely adaptable as possible, C can't assume a particular way of how negative numbers are represented, so defining the consequences of overflowing is intentionally omitted
That's probably because people want it, and web hosts would be quite a failure when not providing what the customer wants. Again, that doesn't make the language less shitty.
My favorite analogy:
Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.
You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.
You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.
You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.
And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.
Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.
That’s what’s wrong with PHP.
(source)
In C, overflowing a signed integer type is undefined behaviour; unsigned type wrap around to zero in a defined manner.
Of course, either is often undesired, but the latter at least doesn't allow basically anything to happen.
I suspect now would be the best time to apply at Boeing :-)
If you did the math, you don't need excess space. If you need excess space, you're just shifting the day of failure into the future. Yes, perhaps far enough, but still.
So it's more of a serious joomla/wordpress security issue, right?
You should see what happens after -2147483648 days of upt-- oh wait.
But applause as MS is truly embracing open source
FTFY. We know what follows.
Easy escape of all others point?
I don't feel like wasting more time with you by deciphering your incoherent gibberish and giving long-ish answers just to find you aren't reading them anyway.
4 more admins to support the same workload on the BSD box compared to a Linux box? Not really efficient. I understand why Linux make you so angry...
Try reading instead of gibbering like a drooling idiot. That was not about supporting a linux server, but supporting a desktop GUI-only installation base for clueless users, you clueless twat.
I bisected a bit
Yeah that's odd. If you add -w to diff, then it reduces to "only" 9 megs. If you look into the diff, you see it's a massive style commit. Removing redundant braces, breaking long lines, indenting preprocessor directives.
They really should have mentioned it in the changelog.
Plus, *adjusts tinfoil hat*, that's exactly the kind of commit where a deliberate change is as easily inserted as it is overlooked...
The fact that a sysadmin use[s] a shell command interpreter d[oes] not imply that the command[s] he call[s] are shell script[s].
So your idea of a sysadmin is someone who keeps typing the same commands over and over again, every day or week, rather than automating them in a script? Good grief.
I think that I have show[n] enough pro[of] that shell scripts are not as essential outside of system V init as you [] claim.
So you don't understand what a proof is, besides not having a faint clue of real-world systems administration. Duly noted.
Now, this do[es]n't prevent anyone [fr]o[m] us[ing] a shell to get a CLI [lol what] and to write some scripts if [they] like to do so. You seem to forget that the maintainers['] decision to switch to systemd is not to remove power [fr]o[m] the users, but to make the maintainers['] work [] eas[ier]
Ah, okay, maybe that's the issue then. Because so far i had assumed systemd would provide immediate benefits to the users, because that's kind of what a million pimply-faced systemd fanboys claim.
s[o] I don't understand how stressed you are about the systemd architecture.
I thought i had made that clear. Anyway, the recent 3-4 comments were more about shell scripting in general than about systemd in particular.
About the comparison between Linux and BSD kernel, you still fail[] to explain why your BSD boxes can't do the work you are so angry to run on Linux boxes.
You clearly are a complete idiot and not paying attention, if you would actually follow this moronic discussion you'd have ran across:
I'd love to have them run *BSDs, but since they're even less meant for the 'GUI-only desktop' use case, the amount of work required to support that would require more than four admins (good ones of which are hard enough to find for linux already).
A reboot for a upgrade will not affect [???] the availability because it only affect[s] the users for a minute or so
Thanks for another demonstration of how all your sysadmin "knowledge" is purely theoretical and pulled out of your ass. Read this.
So I think we can at least agree that the upgrade on Linux is no[t] affecting your operation more that your BSD boxes.
That's only because the Linux server sits around idle unless it's 4am or an office machine is reinstalling.
And if you can really crash a[n] up-to-date Linux kernel so often, then you must see a clear pattern of the subsystem that cause[s] the crash.
I have already realized you're not paying attention, or mentally incapable of doing so, that was in a timespan of at least 5 years. And when talking about "Linux machines i've seen crashing", I'm not specifically referring to that one particular single FAI server. That's not to say that it hadn't had its share of problems, but the bulkload of Linux machines i've seen panicing happened in private contexts. I'm still not sure if you're seriously trying to say that Linux would be free of problems. But you're a troll or a raging zealot, so whatever.
I suspect hat your BSD are in fact netBSD. If this is the case this apply to them: http://www.netbsd.org/support/...
I (obviously) know that p age, and had you cared to actually take a look at it, most of those SAs are userspace related, and we have evaluated every kernel-related one for whether it affects us or not. The user-accessible ssh login gateway was affected to some, and subsequently got rebooted.
Why am i explaining this to an armchair sysadmin?
Restarting services take[s] less time than rebooting (especially with systemd), this is less risky on a remote machine, and
I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts.
And I still call bullshit because scripts are every admin's (and that doesn't even stop with systemd) best and most valuable tool. I don't presume you're seriously going to claim that even admins could completely forgo of the shell? Or would want to do that in the first place? (Hint: automation). If a sys- and network admin entirely using GUIs to do their job is what you imagine, then you're so far away from reality, it's not even funny anymore...
I mentioned busybox to show that binary commands [are] enough to admin a box
And what do you think is the execution environment for literally every single of those tools? Seriously if you were even slower, you'd go backwards.
I have see[n] a lot of Linux boxes with load[s] like the one you describe[d] on your BSD box[es], this is not impressive at all.
That wasn't mean to impress, i was merely responding to your claim about unfair comparisons. Nice try, but it would help if you would consider the parts you reply to in their actual context, instead of trying to create and tear down straw men like this.
Now, did your Linux kernel really crash[]?
Yes, I've seen uncountable instances of linux panicing.
I understand that you reboot for each libc or kernel update, this is your choice, but certainly not a stability problem.
I didn't say the reboots required by updates were a stability problem; they are an availability problem, however.
About the libc update, you might find [it] simple[r] to just reboot, but again this is your choice, not a stability problem. Now in case of libc upgrade[s], [what] [do] you do with your BSD boxes[]? Or [is] the BSD libc [] so perfect that no upgrades [are] required[]? Hint: https://www.freebsd.org/securi...
Hint: It's not FreeBSD, and Hint: if the BSD servers receive a libc update that fixes a security issue we're affected by, then the server gets rebooted. Not that i hadn't already said that in the post before.
You call me ridicul[ous], but I largely prefer restarting some services
if it's a libc fix, "some" services will not cut it.
It's a choice, and I will not call you ridicul[ous] for your own choice.
Well if you choose to go for a reboot-less libc security upgrade just to keep uptime (yet losing availability), then i'd actually ridicule you for that, because it'd be a moronic waste of time. If you get paid by the hour, maybe.
If you are so conservative to reboot each box[] as soon as a libc or kernel upgrade [appears], then I wonder how your BSD boxes could have uptime[s] a "few orders of magnitude less shitty".
See above.
aerospace, or railway, or automotive, or civil engineering standards
So, let's assume you're designing some aerospace-grade embedded system, linux based no less. Would you make it use systemd? Why not?
But I would like to rem[ind] you th[at] this discussion is about the fact [t]hat Ubuntu has released [their] first version with systemd :-)
Sure. Let's see how it works out.
If we talk about the admin work, it's not fair to count /usr/*. On a typical Debian Jessie I have:
file /bin/* /sbin/* | egrep ELF | wc -l
233
file /bin/* /sbin/* | egrep script | wc -l
36
I don't understand why it wouldn't be fair to count /usr. There's no clean separation between what goes into /*bin and what goes into /usr/*bin in Linux; you find many elementary programs in /usr for twisted, for historical and for essentially no particular reason. Even having /usr be a separate partition is not recommended anymore, unless you're into building your own initrd (which non-admins wouldn't ever do, by (your) definition).
And a majority of the scripts are just to make usual commands work on compressed files. So I still hold my claim that the admin work outside of system V init stack is not essentially based on scripts. Far from that actually, and to push this to the limit, just look at the busybox project. I have not verified, but I suspect that a machine with systemd and busybox could be close the be usable for simple tasks without any shell interpreter.
Wow, hold on. Realize what you're saying, please. You're not exactly going to click on the programs provided by busybox in a GUI, are you? Or most of the other programs for that matter. /only/ make sense in a shell, and by extension, are get used in scripts. Why provide busybox at all, otherwise??
It's the very point of busybox to provide a set of programs which
NetworkManager [...] is split into different parts, essentially: 1) the daemon, 2) the CLI, 3) the GUI.
Okay, I wasn't aware of that split. If it's indeed a clean separation, then it's not so bad, indeed.
I would like to also see a Web and SQL interfaces for all of those parts as this is basically what my customers are asking for.
*vomits*
If I understand you correctly your BSD boxs don't run the same kind of applications as the Linux box, so it's not fair to compare the stability of a GUI application by the kernel or distribution where it is executed.
Not sure how a GUI application is related here, FAI clearly is not a GUI and the Linux server obviously doesn't run X11. ;)).
But you're right, it was an unfair comparison, let's see:
The Linux server run: a) PXE/thttpd for network booting, b) nightly cronjobs to do maintenance on the desktops, c) a Debian repository.
The BSD servers are: fileserver, redundant mailservers (smtp(s)/pop3(s)/imap(s)), redundant nameservers, DHCP, httpd, sshd, redundant LDAP, print server, a captive portal for one of three wireless networks, firewalls, NAT gateways, svn server, you-name-it. Probably a few other common services that currently don't come to mind. Essentially a full-fledged, rather traditional production network, with amazing availability. (You know, the kind of thing people mistakenly believe "the cloud" to provide
So, unfair a comparison indeed, but not really the way you meant it, i guess.
You don't have to reboot to update the libc
Don't be ridiculous. Every userspace process directly or indirectly uses libc, so yes, instead of rebooting you could indeed manually stop all the services and kill all remaining tasks until the system is essentially single-user, and then get all the services going again. But no, only a complete idiot would actually do that. For all practical purposes, it would equal a reboot (and underlines my point of high degrees of hand-holding)
and you are free to decide if you like to update you kernel depending on the risk that apply to your situation.
Sure, but there's only one policy here that makes sense, and it equally applies to all
Irony is when the Apple watch survives the fall and starts working once the wrist starts to decompose
Hahah, that caught me by surprise. You owe me one mouth- and half a noseful of coffee.
Windows Idiot was much better than expected.
Well, these last days our Windows support has made Google inaccessible (peer disconnected all the time).
I hate that damn peer guy, he disconnects me from IRC all the time, too. Happen to know where he lives?
*sharpens fists in a giant pencil sharpener*