Even if you're trying to be funny, a falsehood is still a falsehood. So kindly please stop saying things that we know are untrue. Assange has neither been charged with nor convicted of rape. He is innocent until proven guilty, no matter what we know about his actions and lifestyle.
The swedes want him for questioning in regards to two (if I recall correctly) alleged rapes. However it's unlikely that if he did return to Sweden that they would even be able to charge him let alone convict him of rape. But getting him in Swedish custody paves the way for extradition to the United States where the current government wishes to punish him severely for exposing their sins. There's near certainty that's why the Swedes have pursued him thus. And that's why he's fighting this extradition tooth and nail.
It's kind of like how the mob bosses in 1930s Chicago were brought down. They never could make actual charges of murder stick, so they got him on tax evasion. Means to an end for the US government.
Wow, that was an amazing set of videos. Particularly how the machine can do decomposition. What a brilliant man who designed this machine.
All analog computers fascinate me. Apparently analog computers implemented fire control on navy ships for many years, compensating for the speed, direction, and roll of the ship in order to aim guns. The accuracy of such a system was impressive, and they were used up until the 1980s on some older ships. Digital systems simply couldn't get the accuracy for many years.
Well said. There's a lot of disinformation being spread by well-meaning individuals, and by some not-so-well meaning individuals. Especially rubbish like "hybrid seeds are bred... [to] typically need chemicals to thrive." Except that it's strictly true; they do need chemicals like water, CO2, Nitrates to survive. But to say they *need* pesticides suggests that the pesticides are directly causing growth and contributing to the plant, with the innuendo that our food is laced (purposely even) with toxic chemicals, is dishonest.
There are lots of issues at play here with sustaining food production for the future, but articles like this one don't bring anything to the table.
Except that on windows you get the 32 bit baggage whether you want or need it. It's not like Linux where you can install a 64 bit pure distro. So in the Windows world, moving to 64 bits just for the sake of 64 bits doesn't make as much sense. It doesn't save much.
Depending on the accuracy obtained, such mapping would be highly useful on our farm for figuring out drainage. Some areas of a field might drain better with only a very small slope, if we knew where to put the channel. Currently the only real option is to drive over the field with an RTK GPS receiver and make a GIS map of elevations. Which works well enough (depending on the grid resolution; can get really old driving every 10 feet over 160 acres), but takes quite a long time to do.
Yes that's good practice for any command. Though wget is used behind the scenes by, say, opkg on openwrt boxes, which has to run as root since it's unpacking and installing packages. In fact on embedded devices, most everything runs as root there, typically, even if it's a bad idea, and is going to have to change as the internet of things becomes a fact of life. Never thought I'd need to run selinux on an embedded device, but we're to the point now where that's required.
It's good to have this particular bug fixed at least.
Init scripts work just fine in systemd, and will for as long as there are init scripts. So vendors and apps *can* provide systemd service definition files, but they don't have to. It's backwards compatible just like upstart was in RHEL6. So no there's not a loooooooooong drawn out process to make it work. I'm running a debian box right now with systemd and everything is still in init scripts.
I can tell you haven't used systemd then. It doesn't use a registry at all. And services run in the same manner as they do with the init that you're used to. Talk about FUD.
Good thing systemd works better than my own editing skills. That should be something along the lines of "[because of your question] it's readily apparent you have no clue about systemd."
Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.
How so? Systemd has removed my ability to start and stop services?
How would a package mess with systemd's configuration? It's readily apparently no clue about systemd. Hint, it's no different than it was before. A package drops its own service definition file in a directory (sound familiar?). That's it. It's no different in this area than any other init system. If the file is bad, the service just won't start. Just as it was before. Runlevels or targets are defined the same way: with simple symlinks. Really in this aspect, systemd is no different than upstart or plain old system v init.
This post is one example why the debate gets so heated. People like you post stuff that's only nearly half true, without knowing anything about systemd, except the name of one of the authors. FUD plain and simple. A technical debate is fine, but you've got to actually know what you're talking about before you start debating. So far I've seen zero technical debate on this site regarding systemd. Certainly no one is willing to own up to the flaws in traditional init that have led to systemd's development. It's extremely disheartening to see this kind of irrational fear instead of technical discussion.
What Red Hat does is between them and their customers, plain and simple. People can complain about freedom of choice all they want (hint, you still have it), and you, as an experienced admin, are free to plot your own course.
I don't believe Red Hat has made this move on RHEL 7 in error. I think they have a pretty good handle on their customers and their needs. From what I can see on the RHEL lists that have many professional admins, there's been no hue and cry, no sky falling, etc.
I'm not quite sure what a "veteran administrator" is that the article speaks of, but I managed a fair number of servers professionally for quite a few years and I have no problem with systemd. It works stably and well (and no a reboot is not required for most updates as the daemons can be restarted on the fly if necessary). As I've said on many occasions, I've had race conditions completely stop boot scripts in their tracks before (pre-upstart RHEL). Any talk of a binary log is a red herring, plain and simple. Running CentOS 7 right now and syslog is still there, logging away to a normal log file. If one wishes to use it, there is journald to pour through when you need greater granularity and detail in debugging a problem. That has the potential to be of tremendous value for system administrators when tracking down obscure bugs and problems. The traditional syslog is still there to satisfy the record-keeping needs of many organizations, possibly under law in some cases.
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
How does systemd remind you of windows? Have you actually *used* either in a system administration capacity?
What does SSL have to do with it? As you say yourself, as long as you are checking the signing key on each package, you can guarantee that the package is intact and genuine, not matter what the MITM tries to do. The worst that happens with http is that someone can determine which file you downloaded. Hence the injecting of malware can't happen to Linux packages (if the private key is secured by the distro maker). Couldn't happen to any signed executable either, but on Windows users often blindly allow programs to run even with bad signatures.
Obviously there is a way, since their malware driver was detecting it and *then* changing the pid to 0x0000. In fact you can see source code for this that someone posted to the Linux Kernel Mailing list a few days ago. Hopefully the new driver will do exactly as you suggest, though I think a big warning message box saying that the device is not genuine, but continue to function might be enough for end users to let companies know their devices are using the fake chips.
Well the fact of the matter is that Google is only interested in making sure their app store is the only trusted store. The choice to make it all or nothing was deliberate on their part. They could easily have implemented user-selectable trust of signing certificates. Granted 90% of android users don't even understand the problem, let alone the solution.
Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?
So you know the majority of system administrators? That's an awful lot of people.
I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.
This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.
If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.
It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.
Always good to hear things from the original source! Thanks for posting.
Just fyi, your "homepage" link refers to your old Easy Software web site, which no longer exists. Apparently an e-cigarette company has bought up your old domain name!
MS Windows is still the dominant platform, and it doesn't seem to have any guidelines or standard widgets anymore. Every app seems to use s different set of widgets and owner-drawn window decorations are a plague in certain spaces like anti-malware and anti-virus. MS themselves started this trend by using a different set of widgets with every release of MS Office. I just laugh when people talk about Linux apps being all different and not fitting into together. Windows is at least as bad these days, if not worse. And yes Chrome has made the problem even worse, and now Firefox.
If I could use classic theme restorer plus the GTK theme addon for Firefox I'd be a happy camper. As it is I'm stuck on ESR 24 for the time being.
Here's a real product that seems to almost do what the original poster is wanting, but not quite. But the it's a similar solution to what I described, but instead of discarding packets to allow the fasted packet to win, it aggregates bandwidth. Different problem, but similar solution.
Seems like reading and comprehending the question is not doable for most of the folks in the comments of this story today. If you go back and read what the original poster asked, I think you'll realize that it's completely doable, with some (perhaps significant) effort. Certainly there aren't any out -of-box solutions that I know of. Basically a combination of mTCP and VPN is what he's looking for. The multipath connection is not between him and the gaming server. He wants it between him and a VPS running linux. The gaming server part is the final goal, but nothing to do with his problem or question. He certainly could invent his own tunneling protocol using, say UDP. As an example, if we consider the tcp/ip protocol, each packet has a unique sequence number. So if we take a TCP/IP packet, wrap it in a UDP packet and send one to the server through each interface, the server could unpack the UDP packet, note the sequence number, and if it already saw it recently, discard it. Otherwise, make a note of it and drop it onto the internet. On the return trip, acknowledgements would have to be handled on the client side. IE if one ack comes, we can safely ignore any others for the same sequence number. If no acks come from either pathway, then it's a standard timeout. This is TCP/IP only. I'm sure UDP could be encapsulated in a similar way, ICMP also probably.
As I type this, I wonder if this could be done by hacking OpenVPN. OpenVPN already has udp encapsulation of UDP, ICMP, and TCP/IP. It would just be a matter of hacking in some support to send the same packet out multiple interfaces at once, and then logic to track and discard duplicates. Not sure how long either hand would have to track things for, or how much would have to be tracked.
Well you'll be happy to know, then, that plain text log files are alive and well under systemd. They are still there. Really. syslog facility continues to function. The journal provides a fine-grained, extremely searchable facility in addition. As for the journal being binary, that is certainly a good debate to have. But it's not even close to the windows event viewer.
Your comment makes no sense. If you don't like or want to use it then don't! What a bizarre notion. You act as if you're forced to use it. Besides all that you're using something that is provided for free! How dare they mess with my precious linux! If you don't like it, move on. Use something better. You might have to pay for it, but that's the way the world works. Windows 9 with classic shell isn't that bad.
What the op is saying is that whining about free software makes you a freeloader, plain and simple. There is such thing as feedback and criticism, but the crap over systemd passed that line a long time ago.
Citations needed. Please post the bugzilla links to the bugs that the systemd team are ignoring? And what current issues of compatibility are you referring to? I seriously wish to know, and I think folks here would like to know also.
Slashdot Mirror
Even if you're trying to be funny, a falsehood is still a falsehood. So kindly please stop saying things that we know are untrue. Assange has neither been charged with nor convicted of rape. He is innocent until proven guilty, no matter what we know about his actions and lifestyle.
The swedes want him for questioning in regards to two (if I recall correctly) alleged rapes. However it's unlikely that if he did return to Sweden that they would even be able to charge him let alone convict him of rape. But getting him in Swedish custody paves the way for extradition to the United States where the current government wishes to punish him severely for exposing their sins. There's near certainty that's why the Swedes have pursued him thus. And that's why he's fighting this extradition tooth and nail.
It's kind of like how the mob bosses in 1930s Chicago were brought down. They never could make actual charges of murder stick, so they got him on tax evasion. Means to an end for the US government.
Yes I agree. I was wondering if Microsoft was going to be shipping the patch to customers on tapes, or what.
Wow, that was an amazing set of videos. Particularly how the machine can do decomposition. What a brilliant man who designed this machine.
All analog computers fascinate me. Apparently analog computers implemented fire control on navy ships for many years, compensating for the speed, direction, and roll of the ship in order to aim guns. The accuracy of such a system was impressive, and they were used up until the 1980s on some older ships. Digital systems simply couldn't get the accuracy for many years.
https://www.youtube.com/watch?...
Slide rules are very cool as well. I want to learn how to use one.
Well said. There's a lot of disinformation being spread by well-meaning individuals, and by some not-so-well meaning individuals. Especially rubbish like "hybrid seeds are bred... [to] typically need chemicals to thrive." Except that it's strictly true; they do need chemicals like water, CO2, Nitrates to survive. But to say they *need* pesticides suggests that the pesticides are directly causing growth and contributing to the plant, with the innuendo that our food is laced (purposely even) with toxic chemicals, is dishonest.
There are lots of issues at play here with sustaining food production for the future, but articles like this one don't bring anything to the table.
Except that on windows you get the 32 bit baggage whether you want or need it. It's not like Linux where you can install a 64 bit pure distro. So in the Windows world, moving to 64 bits just for the sake of 64 bits doesn't make as much sense. It doesn't save much.
Depending on the accuracy obtained, such mapping would be highly useful on our farm for figuring out drainage. Some areas of a field might drain better with only a very small slope, if we knew where to put the channel. Currently the only real option is to drive over the field with an RTK GPS receiver and make a GIS map of elevations. Which works well enough (depending on the grid resolution; can get really old driving every 10 feet over 160 acres), but takes quite a long time to do.
Yes that's good practice for any command. Though wget is used behind the scenes by, say, opkg on openwrt boxes, which has to run as root since it's unpacking and installing packages. In fact on embedded devices, most everything runs as root there, typically, even if it's a bad idea, and is going to have to change as the internet of things becomes a fact of life. Never thought I'd need to run selinux on an embedded device, but we're to the point now where that's required.
It's good to have this particular bug fixed at least.
Init scripts work just fine in systemd, and will for as long as there are init scripts. So vendors and apps *can* provide systemd service definition files, but they don't have to. It's backwards compatible just like upstart was in RHEL6. So no there's not a loooooooooong drawn out process to make it work. I'm running a debian box right now with systemd and everything is still in init scripts.
I can tell you haven't used systemd then. It doesn't use a registry at all. And services run in the same manner as they do with the init that you're used to. Talk about FUD.
Good thing systemd works better than my own editing skills. That should be something along the lines of "[because of your question] it's readily apparent you have no clue about systemd."
How so? Systemd has removed my ability to start and stop services?
How would a package mess with systemd's configuration? It's readily apparently no clue about systemd. Hint, it's no different than it was before. A package drops its own service definition file in a directory (sound familiar?). That's it. It's no different in this area than any other init system. If the file is bad, the service just won't start. Just as it was before. Runlevels or targets are defined the same way: with simple symlinks. Really in this aspect, systemd is no different than upstart or plain old system v init.
This post is one example why the debate gets so heated. People like you post stuff that's only nearly half true, without knowing anything about systemd, except the name of one of the authors. FUD plain and simple. A technical debate is fine, but you've got to actually know what you're talking about before you start debating. So far I've seen zero technical debate on this site regarding systemd. Certainly no one is willing to own up to the flaws in traditional init that have led to systemd's development. It's extremely disheartening to see this kind of irrational fear instead of technical discussion.
What Red Hat does is between them and their customers, plain and simple. People can complain about freedom of choice all they want (hint, you still have it), and you, as an experienced admin, are free to plot your own course.
I don't believe Red Hat has made this move on RHEL 7 in error. I think they have a pretty good handle on their customers and their needs. From what I can see on the RHEL lists that have many professional admins, there's been no hue and cry, no sky falling, etc.
I'm not quite sure what a "veteran administrator" is that the article speaks of, but I managed a fair number of servers professionally for quite a few years and I have no problem with systemd. It works stably and well (and no a reboot is not required for most updates as the daemons can be restarted on the fly if necessary). As I've said on many occasions, I've had race conditions completely stop boot scripts in their tracks before (pre-upstart RHEL). Any talk of a binary log is a red herring, plain and simple. Running CentOS 7 right now and syslog is still there, logging away to a normal log file. If one wishes to use it, there is journald to pour through when you need greater granularity and detail in debugging a problem. That has the potential to be of tremendous value for system administrators when tracking down obscure bugs and problems. The traditional syslog is still there to satisfy the record-keeping needs of many organizations, possibly under law in some cases.
As for the unix philosophy, init systems pre-systemd hardly did just one thing and hardly did it well.
How does systemd remind you of windows? Have you actually *used* either in a system administration capacity?
What does SSL have to do with it? As you say yourself, as long as you are checking the signing key on each package, you can guarantee that the package is intact and genuine, not matter what the MITM tries to do. The worst that happens with http is that someone can determine which file you downloaded. Hence the injecting of malware can't happen to Linux packages (if the private key is secured by the distro maker). Couldn't happen to any signed executable either, but on Windows users often blindly allow programs to run even with bad signatures.
Obviously there is a way, since their malware driver was detecting it and *then* changing the pid to 0x0000. In fact you can see source code for this that someone posted to the Linux Kernel Mailing list a few days ago. Hopefully the new driver will do exactly as you suggest, though I think a big warning message box saying that the device is not genuine, but continue to function might be enough for end users to let companies know their devices are using the fake chips.
Well the fact of the matter is that Google is only interested in making sure their app store is the only trusted store. The choice to make it all or nothing was deliberate on their part. They could easily have implemented user-selectable trust of signing certificates. Granted 90% of android users don't even understand the problem, let alone the solution.
Still, though, this vulnerability appears to be firmly in the area of social engineering because why would I want to download an encrypted image file that requires another separate, random app to decrypt and view it?
So you know the majority of system administrators? That's an awful lot of people.
I follow the RHEL mailing list and there are a lot of very smart sysadmins on that list, and none of them have expressed any concern or even comment about systemd. And it's certainly shipping, and it's been on the roadmap for some time. In short, for many people it's a non issue.
This is, by all appearances, a tempest in a teacup, mostly existing here on on slashdot, where groupthink has moved against systemd without any real argument against it other than mumblings about philosophy, or theoretical problems that haven't been shown to even exist in systemd.
If these "supervision" frameworks of which you speak were redundant, then why do they exist in the first place? Clearly system v has had some pretty big limitations. I've personally hacked many a cronjob to supervise processes started by sys v init scripts (some of the init scripts I wrote myself... yuck). Also as servers move into virtual space, and deal with hotplugging of various resources, it just wasn't enough. Took years to get consistent naming on network interfaces, for example, and even then I could never be sure which interface was which when I first brought them up (they usually followed motherboard numbering, but not always). To say nothing of adding other hotplug interfaces of different sorts. Even after the udev hacks brought some sanity, every time I'd change out a network card, or clone it to a new system with a new MAC address I'd have to either delete the udev config for it, or have it change to eth1, eth2, etc. And by the way, it's not even systemd that does all this now, it's systemd-udevd. So it's still modular and you could replace systemd with uselessd, and then run a separately-packaged udev.
It's also telling that other major commerical Unix vendors (say, Solaris, for example) have abandoned sys v init as well, or at least abandoned shell scripts as part of the init system, for a more comprehensive and capable system and framework. I'm not sure if Apple ever used system v init, but they certainly abandoned the script system in general with 10.4 and LaunchDaemon. They had good reasons to do so.
Not always. His yacht was hideous!
Always good to hear things from the original source! Thanks for posting.
Just fyi, your "homepage" link refers to your old Easy Software web site, which no longer exists. Apparently an e-cigarette company has bought up your old domain name!
MS Windows is still the dominant platform, and it doesn't seem to have any guidelines or standard widgets anymore. Every app seems to use s different set of widgets and owner-drawn window decorations are a plague in certain spaces like anti-malware and anti-virus. MS themselves started this trend by using a different set of widgets with every release of MS Office. I just laugh when people talk about Linux apps being all different and not fitting into together. Windows is at least as bad these days, if not worse. And yes Chrome has made the problem even worse, and now Firefox.
If I could use classic theme restorer plus the GTK theme addon for Firefox I'd be a happy camper. As it is I'm stuck on ESR 24 for the time being.
Here's a real product that seems to almost do what the original poster is wanting, but not quite. But the it's a similar solution to what I described, but instead of discarding packets to allow the fasted packet to win, it aggregates bandwidth. Different problem, but similar solution.
http://www.pcpro.co.uk/news/br...
Seems like reading and comprehending the question is not doable for most of the folks in the comments of this story today. If you go back and read what the original poster asked, I think you'll realize that it's completely doable, with some (perhaps significant) effort. Certainly there aren't any out -of-box solutions that I know of. Basically a combination of mTCP and VPN is what he's looking for. The multipath connection is not between him and the gaming server. He wants it between him and a VPS running linux. The gaming server part is the final goal, but nothing to do with his problem or question. He certainly could invent his own tunneling protocol using, say UDP. As an example, if we consider the tcp/ip protocol, each packet has a unique sequence number. So if we take a TCP/IP packet, wrap it in a UDP packet and send one to the server through each interface, the server could unpack the UDP packet, note the sequence number, and if it already saw it recently, discard it. Otherwise, make a note of it and drop it onto the internet. On the return trip, acknowledgements would have to be handled on the client side. IE if one ack comes, we can safely ignore any others for the same sequence number. If no acks come from either pathway, then it's a standard timeout. This is TCP/IP only. I'm sure UDP could be encapsulated in a similar way, ICMP also probably.
As I type this, I wonder if this could be done by hacking OpenVPN. OpenVPN already has udp encapsulation of UDP, ICMP, and TCP/IP. It would just be a matter of hacking in some support to send the same packet out multiple interfaces at once, and then logic to track and discard duplicates. Not sure how long either hand would have to track things for, or how much would have to be tracked.
Now if we can just get them all to sign up and donate money.
Well you'll be happy to know, then, that plain text log files are alive and well under systemd. They are still there. Really. syslog facility continues to function. The journal provides a fine-grained, extremely searchable facility in addition. As for the journal being binary, that is certainly a good debate to have. But it's not even close to the windows event viewer.
Your comment makes no sense. If you don't like or want to use it then don't! What a bizarre notion. You act as if you're forced to use it. Besides all that you're using something that is provided for free! How dare they mess with my precious linux! If you don't like it, move on. Use something better. You might have to pay for it, but that's the way the world works. Windows 9 with classic shell isn't that bad.
What the op is saying is that whining about free software makes you a freeloader, plain and simple. There is such thing as feedback and criticism, but the crap over systemd passed that line a long time ago.
Citations needed. Please post the bugzilla links to the bugs that the systemd team are ignoring? And what current issues of compatibility are you referring to? I seriously wish to know, and I think folks here would like to know also.