> I'm not one of them, but it appears some people prefer to break everything by updating a single shared library.
That is a problem. But not with the system.
> The thing is if your program requires a specific, not necessarily common shared library, it's not very portable.
As long as it's source, you can compile it (unless it needs 2.4 kernel bindings on 2.6, or some such)
> That's why this article is news. Portability should have always been easy. Common hardware drivers should be shared, yes, but that's as far as it should go. It helps to minimize those nasty little problems of missing or incompatible libraries.
Security nightmare. Shared libraries are shared for a lot of reasons, security is one of the major concerns.
> My aim is for ease of use for the end user, not really to make it easy for the developer, though that would be nice. Maybe that's where the problem is. Few people are thinking of the user.
My aim is to fix the root of the problem (devs not knowing what they do), not the symptoms.
> The real problem is that Linux distributions, taken together or individually, presents developers with too many completely unnecessary choices as to where essential library files can be put, and also, there is no standard version naming and locating convention.
Do you need it to boot? Prefix is/ Do you need it after boot? Prefix is/usr Do you want to install custom stuff that is not handled via the system's default software handling solution? Prefix is/usr/local or/opt Do you want to install into home dir? Prefix is ~/local or ~/opt If you are in a heterogenous environment with shared home between lots of architectures etc,/import/x86 etc is a good place
This leads to clean & clear separation of software after a system people poured a lot of thought into. Is it easy to grasp at first sight for someone used to Windows? No. But that is _not_ the priority. Sorry, it's not. People writing code need to learn how the language works. Why shouldn't they learn how to system works?
> Package managers are a complex solution to a problem that need not have existed in the first place, if it was realized that unnecessary choice is deadly dangerous, in the world of large-scale software interoperability.
Yeah, cause grabbing random downloads of.bat,.exe,.msi,.whatnot turned out to be awesome. Especially the integrated updates. Oh, what's that? Everyone is implementing their own system leading to dozens of parallel update mechanisms on a single machine? Now _that_ is efficient! And the programs that don't have an update routine? Simple, just write them bug-free, without holes and a complete feature set in 1.0!
> There does not need to be any choice for where on a file system a given application or a given library should be located.
That is true if you consider every machine to be an island. Unix thrived and continues to thrive cause you can create huge shared environments with almost no work.
> That should be completely determined by the app or library name, version (using a standard versioning scheme), variant (using a standard variant naming scheme), and origin person-or-organization, using a standard organization identifying scheme.
My custom mplayer is in/usr/local/mplayer. My custom git is in/usr/local/git. My custom vim is in/usr/local/vim. I can delete any of those and remove the program, along with all its libraries and whatnot, with one single rm. If devs simply don't know that they should default to/usr/local for stuff, again... It's their problem, same as if they did not know how to open() a file.
> It goes without saying that there should also be a standard globally unique URI for such libraries and apps (including the unique name, version, variant, origin identification).
No. No. No. This breaks any and all assumptions about being able to install different versions of stuff for different reasons. Use prefixes and use LD_PATH, etc.
> So there should be no choice about where on the internet to get it (except for the choice involved in a standard mirroring URI scheme), and no choice about where to put it.
Maybe you are too young to have seen this yourself, but after a few years, most URLs are dead. With gittorrent, ideally with a DHT sprinkled on top, this might change in the longer run, but what if the next VCS that whoops git's ass comes along? Static information on the internet is mostly a myth. (Also, git would need to get rid of SHA1 for fully automated code distribution, imo)
> With this discipline, obviously needed in today's universe of code, all such package management, as well as dependency acquisition and installation, could be managed by a single unified and incredibly simple automated package manager; call it the
Only if you update those sandboxes. Else, you will have various sandboxes with different patch levels. And you will have exactly the same bug in a dozen sandboxes.
Pretty much, but I still feel the need to point out that you are misinterpreting what I said; on purpose or not.
Again: I did _not_ condone or defend the misrepresentation that happened.
All I am saying, repeatedly, is that the conclusion they came to is scientifically sound.
You are so focused on your point that you ignore everything I say, trying to force me into debate about truth. If you had stated so earlier, we could have stopped earlier.
Government lives and thrives on lies. It pains me to say this, but the pain dulls at some point. I'd rather be outraged and try to effect change when the outcome is negative. There is not enough outrage and/or time to really care about it all.
And it's not my government. If it was, I would have emigrated years ago. From visiting both the USA and Canada, I'd say Vancouver is a good place.
> Regardless of what some Climate scientists will tell you, there's no 'value added' in purposefully manipulating data to show what you want the data to show.
If you are referring to Climategate:
a) You are mixing different topics b) It has been debunked again and again
> There's nothing in the Scientific Method that suggests that it's ok to swap the statements of panel around to make it appear as though they are recommending something they are not.
Correct. And I did not claim that was the case.
> There's nothing shady about making your case based on scientific analysis. There's nothing wrong with taking the information provided by a group and pleading your case using that as evidence. There's something very wrong, however, in making it appear as though the people you used evidence from made the recommendations that you are trying to make for yourself when they did nothing of the sort.
Unrelated.
> It doesn't really matter at all if you agree with the White House conclusions or not. If the means is lies and deceit then the ends are inherently suspect. If you cant make your case out in the open then maybe you should re-evaluate how valid your position actually is. Unfortunately this line of reasoning is becoming less and less common in acedemia.
Guilt by association much? "inherently suspect" is a tad strong, imo. Especially since the chain of thought "something went horribly wrong, let's stop similar things until we know why" is not exactly all that new. Of course, they will come up with all the wrong conclusions after the moratorium, this time directly going against the proven-to-be-working mechanisms that are enforced in the North Sea with some made-up mumbo-jumbo which boils down to maximizing profits. _Then_ you can rant with the above.
Or to put it another way: Do you disagree that the moratorium itself, no matter what was used to justify it, is scientifically sound?
> The ends justify the means. It's all better now. Move along.
I fear you did not actually understand what I said.
Quoth the blurb: "This follows complaints from scientists and environmentalists that the administration has not been holding to its promise of policy guided by science and not ideology."
Replies the RichiH: "Yet, the _end_ to which they did it sounds scientific to me."
I did not condone their purported action in any way. I merely pointed out that their policy is science-driven and not ideology-driven./end_explanation
...obviously, the concept the Aussie gvt is pushing is beyond bat-shit crazy.
That being said, any ISP which does not have a VCS with _all_ configs of all network devices at any time is equally crazy. Unless they are generating their config from templates in which case they should have those sources in a VCS.
> The scientists didn't think it prudent, and when asked about it after the fact said they definitely would not have recommended it.
Those didn't, OK. The reports and studies I read urged an immediate moratorium.
> If you just had a oil well explode in a failed capping operation
Failed capping of a well that has no structural integrity due to the fact that it's not cement-clad. Failed capping of a well that has no sarcophagus you can simple slam shut and figure out a solution without oil gushing out. Failed capping of a well that has been pushed along at an insane pace. Failed capping of a well WHICH BLOWOUT PREVENTER WAS DESTROYED BY HUMAN ERROR and _still_ continuing to drill.
Number 4 may be unique to Deep Horizon. The rest is not. And you know what they did with the other wells while they couldn't drill? They built sarcophagi.
You can not possibly argue that this is not a factual & scientific advantage.
> what kind of idiot would order 60 more just like it, just in case it happens again? That's like accidentally cutting your finger off with a butcher knife, and then seeing if you can miss each of your other 9 fingers, just in case.
Dunno, when the largest oil blowout (it was not a spill!) happens, most people would think it prudent to stop and check all other similar endeavors. Maybe they misrepresented stuff on purpose. Yet, the _end_ to which they did it sounds scientific to me.
Though the real question is why you can drill in the US waters without a cement-clad drill hole and a ready-made emergency sarcophagus already in place before you even start drilling. We have those requirements in Europe and people still make gobs of money with oil.
1) I can sniff and use the credentials later. Matter of fact, I would _only_ do that as I _know_ the other guy is active atm. 2) It tells you if you are being sniffed after the fact 3) Use a VPN while on public, shared networks. Always.
As my brain is starting to melt every time I try to understand what is going on....: Does anyone have a link to an animation which explains how this works?
> How do you know that running on an AMD doesn't affect one kernel version more than another vs Intel.
It does, at least if you compile for it.
> There are many people who have interest in virtualized performance.
I am amongst them. We run a few hundred VMs.
> Sure, it's not what you want, but don't consider it completely invalid.
Not completely invalid. Yet, a very basic mistake in benchmarking was made due to inability and/or laziness which could have a major impact on the validity. We are used to this behavior by Phoronix. I am sick and tired of people pretending that is not the case.
How do you know that running in a VM doesn't affect one kernel version more than another?
Being too lazy/stupid to start a machine on bare metal? Come the fuck on.
Of course, Phoronix being the vile pretend-useful bottom-feeding site that it is, they would never care about making sure there are no outside factors over generating page impressions quickly and cheaply.
> Sorry, we support the N900 but not the N810. There are just so many mobile hardware and software variations, we don't have the time to make Fennec run properly on them all I'm afraid.
Did you mean "any more"? I have Fennec running on my N810 as we speak..
Slashdot Mirror
youtube.com/html5
youtube.com/html5
That's the reason why I allow youtube to store cookies on my machine.
> I'm not one of them, but it appears some people prefer to break everything by updating a single shared library.
That is a problem. But not with the system.
> The thing is if your program requires a specific, not necessarily common shared library, it's not very portable.
As long as it's source, you can compile it (unless it needs 2.4 kernel bindings on 2.6, or some such)
> That's why this article is news. Portability should have always been easy. Common hardware drivers should be shared, yes, but that's as far as it should go. It helps to minimize those nasty little problems of missing or incompatible libraries.
Security nightmare. Shared libraries are shared for a lot of reasons, security is one of the major concerns.
> My aim is for ease of use for the end user, not really to make it easy for the developer, though that would be nice. Maybe that's where the problem is. Few people are thinking of the user.
My aim is to fix the root of the problem (devs not knowing what they do), not the symptoms.
For everything else, read http://slashdot.org/comments.pl?sid=1866538&cid=34214686
> but I for one am glad that people are still dreaming, and experimenting!
Until your plane hits one of those experiments. Or something drops on you from 20 km height.
Sorry if topic sounds a tad personal, but hey...
> The real problem is that Linux distributions, taken together or individually, presents developers with too many completely unnecessary choices as to where essential library files can be put, and also, there is no standard version naming and locating convention.
Do you need it to boot? Prefix is / /usr /usr/local or /opt /import/x86 etc is a good place
Do you need it after boot? Prefix is
Do you want to install custom stuff that is not handled via the system's default software handling solution? Prefix is
Do you want to install into home dir? Prefix is ~/local or ~/opt
If you are in a heterogenous environment with shared home between lots of architectures etc,
This leads to clean & clear separation of software after a system people poured a lot of thought into. Is it easy to grasp at first sight for someone used to Windows? No. But that is _not_ the priority. Sorry, it's not. People writing code need to learn how the language works. Why shouldn't they learn how to system works?
> Package managers are a complex solution to a problem that need not have existed in the first place, if it was realized that unnecessary choice is deadly dangerous, in the world of large-scale software interoperability.
Yeah, cause grabbing random downloads of .bat, .exe, .msi, .whatnot turned out to be awesome. Especially the integrated updates. Oh, what's that? Everyone is implementing their own system leading to dozens of parallel update mechanisms on a single machine? Now _that_ is efficient! And the programs that don't have an update routine? Simple, just write them bug-free, without holes and a complete feature set in 1.0!
> There does not need to be any choice for where on a file system a given application or a given library should be located.
That is true if you consider every machine to be an island. Unix thrived and continues to thrive cause you can create huge shared environments with almost no work.
> That should be completely determined by the app or library name, version (using a standard versioning scheme), variant (using a standard variant naming scheme), and origin person-or-organization, using a standard organization identifying scheme.
My custom mplayer is in /usr/local/mplayer. My custom git is in /usr/local/git. My custom vim is in /usr/local/vim. I can delete any of those and remove the program, along with all its libraries and whatnot, with one single rm. /usr/local for stuff, again... It's their problem, same as if they did not know how to open() a file.
If devs simply don't know that they should default to
> It goes without saying that there should also be a standard globally unique URI for such libraries and apps (including the unique name, version, variant, origin identification).
No. No. No. This breaks any and all assumptions about being able to install different versions of stuff for different reasons. Use prefixes and use LD_PATH, etc.
> So there should be no choice about where on the internet to get it (except for the choice involved in a standard mirroring URI scheme), and
no choice about where to put it.
Maybe you are too young to have seen this yourself, but after a few years, most URLs are dead. With gittorrent, ideally with a DHT sprinkled on top, this might change in the longer run, but what if the next VCS that whoops git's ass comes along? Static information on the internet is mostly a myth. (Also, git would need to get rid of SHA1 for fully automated code distribution, imo)
> With this discipline, obviously needed in today's universe of code, all such package management, as well as dependency acquisition and installation, could be managed by a single unified and incredibly simple automated package manager; call it the
Only if you update those sandboxes. Else, you will have various sandboxes with different patch levels. And you will have exactly the same bug in a dozen sandboxes.
> Oh, right. The debate is over...
Pretty much, but I still feel the need to point out that you are misinterpreting what I said; on purpose or not.
Again: I did _not_ condone or defend the misrepresentation that happened.
All I am saying, repeatedly, is that the conclusion they came to is scientifically sound.
You are so focused on your point that you ignore everything I say, trying to force me into debate about truth. If you had stated so earlier, we could have stopped earlier.
Government lives and thrives on lies. It pains me to say this, but the pain dulls at some point. I'd rather be outraged and try to effect change when the outcome is negative. There is not enough outrage and/or time to really care about it all.
And it's not my government. If it was, I would have emigrated years ago. From visiting both the USA and Canada, I'd say Vancouver is a good place.
And I never said they did. Read the other threads.
> Regardless of what some Climate scientists will tell you, there's no 'value added' in purposefully manipulating data to show what you want the data to show.
If you are referring to Climategate:
a) You are mixing different topics
b) It has been debunked again and again
> There's nothing in the Scientific Method that suggests that it's ok to swap the statements of panel around to make it appear as though they are recommending something they are not.
Correct. And I did not claim that was the case.
> There's nothing shady about making your case based on scientific analysis. There's nothing wrong with taking the information provided by a group and pleading your case using that as evidence. There's something very wrong, however, in making it appear as though the people you used evidence from made the recommendations that you are trying to make for yourself when they did nothing of the sort.
Unrelated.
> It doesn't really matter at all if you agree with the White House conclusions or not. If the means is lies and deceit then the ends are inherently suspect. If you cant make your case out in the open then maybe you should re-evaluate how valid your position actually is. Unfortunately this line of reasoning is becoming less and less common in acedemia.
Guilt by association much? "inherently suspect" is a tad strong, imo. Especially since the chain of thought "something went horribly wrong, let's stop similar things until we know why" is not exactly all that new.
Of course, they will come up with all the wrong conclusions after the moratorium, this time directly going against the proven-to-be-working mechanisms that are enforced in the North Sea with some made-up mumbo-jumbo which boils down to maximizing profits. _Then_ you can rant with the above.
Or to put it another way: Do you disagree that the moratorium itself, no matter what was used to justify it, is scientifically sound?
> The ends justify the means. It's all better now. Move along.
I fear you did not actually understand what I said.
Quoth the blurb:
"This follows complaints from scientists and environmentalists that the administration has not been holding to its promise of policy guided by science and not ideology."
Replies the RichiH:
"Yet, the _end_ to which they did it sounds scientific to me."
I did not condone their purported action in any way. I merely pointed out that their policy is science-driven and not ideology-driven. /end_explanation
...obviously, the concept the Aussie gvt is pushing is beyond bat-shit crazy.
That being said, any ISP which does not have a VCS with _all_ configs of all network devices at any time is equally crazy. Unless they are generating their config from templates in which case they should have those sources in a VCS.
> The scientists didn't think it prudent, and when asked about it after the fact said they definitely would not have recommended it.
Those didn't, OK. The reports and studies I read urged an immediate moratorium.
> If you just had a oil well explode in a failed capping operation
Failed capping of a well that has no structural integrity due to the fact that it's not cement-clad.
Failed capping of a well that has no sarcophagus you can simple slam shut and figure out a solution without oil gushing out.
Failed capping of a well that has been pushed along at an insane pace.
Failed capping of a well WHICH BLOWOUT PREVENTER WAS DESTROYED BY HUMAN ERROR and _still_ continuing to drill.
Number 4 may be unique to Deep Horizon. The rest is not. And you know what they did with the other wells while they couldn't drill? They built sarcophagi.
You can not possibly argue that this is not a factual & scientific advantage.
> what kind of idiot would order 60 more just like it, just in case it happens again? That's like accidentally cutting your finger off with a butcher knife, and then seeing if you can miss each of your other 9 fingers, just in case.
Huh?
For the same reason why the fucking American companies build that shit over here:
They are doing the absolute bare minimum they can get by with. Obvious? Yes.
Cause there can only be one.
This is idea is few dozens to hundreds of years old. Way to go, /.
In related news, my concept city, which I do not plan to calculate or verify otherwise, is on the moon and uses unicorn bone dust for power.
Dunno, when the largest oil blowout (it was not a spill!) happens, most people would think it prudent to stop and check all other similar endeavors. Maybe they misrepresented stuff on purpose. Yet, the _end_ to which they did it sounds scientific to me.
Though the real question is why you can drill in the US waters without a cement-clad drill hole and a ready-made emergency sarcophagus already in place before you even start drilling. We have those requirements in Europe and people still make gobs of money with oil.
> Hell, I get concerned about my machine if I get a crash each month.
I get a hang-up every three to six months and it's annoying me to no end. Debian Sid turned stable turned Sid that followed me for years.
So yah, GP seems to be a tad delusional/masochistic in his review.
1) I can sniff and use the credentials later. Matter of fact, I would _only_ do that as I _know_ the other guy is active atm.
2) It tells you if you are being sniffed after the fact
3) Use a VPN while on public, shared networks. Always.
The people who run their diesel cars on used & filtered french fry fat drive cars that smell very tasty.
Unless they strip that out, the cars would smell of chicken.
Personally, I think I would prefer a stripped-down version. Don't make the smell overwhelming, but keep a sprinkle of good smell in there.
Thanks. And yes, http://www.youtube.com/watch?v=UGRFb8yNtBo is the best one by far. The only one I needed.
As my brain is starting to melt every time I try to understand what is going on....: Does anyone have a link to an animation which explains how this works?
Yes, because there's nothing starting an initiative of mutually beneficial and required openness to isolate projects and to put up walls.
That's the reason why the GPL failed to ever gain traction, you know?
> How do you know that running on an AMD doesn't affect one kernel version more than another vs Intel.
It does, at least if you compile for it.
> There are many people who have interest in virtualized performance.
I am amongst them. We run a few hundred VMs.
> Sure, it's not what you want, but don't consider it completely invalid.
Not completely invalid. Yet, a very basic mistake in benchmarking was made due to inability and/or laziness which could have a major impact on the validity.
We are used to this behavior by Phoronix. I am sick and tired of people pretending that is not the case.
How do you know that running in a VM doesn't affect one kernel version more than another?
Being too lazy/stupid to start a machine on bare metal? Come the fuck on.
Of course, Phoronix being the vile pretend-useful bottom-feeding site that it is, they would never care about making sure there are no outside factors over generating page impressions quickly and cheaply.
> Sorry, we support the N900 but not the N810. There are just so many mobile hardware and software variations, we don't have the time to make Fennec run properly on them all I'm afraid.
Did you mean "any more"? I have Fennec running on my N810 as we speak..