Some of us have actually worked in environments like that.
You know, as much as I'd love to zip-thud and reveal my realworld identity and confirm that not only am I telling the truth, but I can provide specific examples, I am bound by an NDA and company policy that prohibits me from disclosing who I work for on social media.
I stand by what I said; The wide variety of linux distributions, software versions, differing packaging applications, etc., makes patch management and software deployment a nightmare. Every place that I have worked at where linux was used, has experienced major logistical headaches. Part of this is due to a lack of labor resources that are adequately trained in Linux, but a lot of it is that there aren't any enterprise-grade tools to make it easy. Most companies that support a lot of linux systems have rolled their own deployment infrastructure and have tried to standardize on one specific distribution to limit the amount of testing and validation needed.
Professionally, I can't recommend linux for anything other than servers and embedded solutions where the systems will run for years without being overhauled and that the only security patches to be applied will be for public-facing services.
That's just the reality of the industry. I have no attachment to Microsoft products; I've used MacOS, Linux, Windows... along with a variety of other now-defunct platforms like OS/2 Warp, BeOS, even CP/M. I'm "agnostic" about operating systems. My job as an IT professional is to facilitate the business process using the tools and resources given to me.
No. With SSD caching you get all the capacity of rotating disks with > 80% of the speed of SSDs. That is not the worst of boths worlds. It is the best of one and most of the other.
No; You can achieve that with a separate SSD and a mechanical drive; That's what most people are doing now anyway.
By putting the two together, what you're basically getting is a mechanical drive with a massively large cache. And because you now have two drives married behind a single logical interface, you've decreased the life expectancy further -- if either fails, it's a boat anchor.
I believe I speak for the majority here when I say.... D'ARGH! KILL IT WITH FIRE NOW! This is yet another pathetic attempt by WD to marry it's crappy line of mechanical drives to SSDs in order to stretch their relevance out a little bit longer and keep them from having to retool their assembly lines and such to produce SSDs exclusively. Weeeell, good for you guys. But as my father would say: "Shit or get off the pot." Either switch to SSDs, and eat the cost, or stick with mechanical drives because they're cheap. But don't waffle and try to do both; You're getting the worst of both worlds then.
That's not an unmitigated good however, especially if you want to make edits but not commit them until you're done. Unix gets it mostly right in that I can send a NOHUP to tell the other process to reload.
Look, all I'm saying is that as far as ease of use, Linux fails here. I'm not saying linux can't perform well, or that it doesn't get the job done, etc., etc. What I am saying is that it's way of organizing configuration options is about thirty years old. Newer things have come along since, with clear advantages. Do they have disadvantages of their own? Of course.
But linux would benefit enormously from advancing to at least a central repository for application and operating system settings. If it's feeling particularly daring, it could even look at what Microsoft has done with.net assemblies and COM architecture. But, you know, baby steps...
You are a completely ignorant moron not really worth responding to. You are a very incompetent troll.
Yet I make way more money than you could even dream of doing network administration for a Fortune 100 business with over 150,000 workstations. Every night, I push out a half-dozen new applications, patches, and OS installs. Yes, I must be a troll... because I disagreed with your religious persuasions and am making an argument based on facts widely supported by market research and years of professional experience... whereas you're busy emoting on religious furvor.
In other words you're unemployed and living in your mother's basement. Your weak attempts at bluster impresses NO ONE here.
I think you're referring to yourself here, buddy. I'm going out this weekend to buy a new car...
You have no real clue abut Linux or corporate computing.
I know what technologies are in use at over a dozen Fortune 100 companies, and I'm familiar with them. And you know what -- none of them are looking for a boat load of linux administrators. There are reasons for this, whether you want to believe them or not.
As far as "just works" goes. Nothing that MacOS or WinDOS has can touch a Linux package manager.
SCCM: I push a button. 140,000 machines get updated with the next security patch. I get a nice report showing any failures, and pass this on to my remediation team to follow up on.
Linux: I push a button. Then I push a few more buttons. Then I puzzle over/var/log/debug... then I recompile the kernel. Then I try deploying the kernel to a few other workstations. Then I find out that some of the modules that I thought weren't needed, were. I recompile the kernel again. Now I deploy the kernel and updated application. About half of the boxes stop booting up. I spend the next few hours paging data centers to reboot them and what special lines to enter into the "boot:" prompt to get it working again. Finally, I get the kernel and application deployed. The application crashes because it expected libc6 instead of libc5. At the end of all of this, I write a custom script to generate a report for me telling me which workstations got installed, which didn't, and if so, how they failed. I write it in Perl, because... Perl. A week later, the application is patched and the phone has stopped ringing from angry users. I open up my inbox... It's another request for a patch. I open my desk drawer, take out the gun, and shoot myself in the head.
Why on earth would I want to cram everything into a central repository?
This is a question that's been asked and answered a great many times, if you care to google it. I won't bother going into all of the benefits over centralization... but the biggest one is concurrently running applications: A change in the registry means the applications that access that key get the new value in real time. A file doesn't necessarily do that; Especially if it's been locked for writing.
Does ldconfig allow for different versions of the same library to be requested by the application?
Yes.
Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.
Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.
Again, read the man page. You can specify which directories it uses to build its cache. That's it. There's no "precision" in that; And if you think I'm going to grep a few thousand lines of output to figure out which library it matched first, you've clearly spent too much time as a user and not enough time as a system administrator. I want something that just works... not having to screw around with a dozen/etc/ config files and another half dozen commands to suss out what went wrong everytime I upgrade a library or application.
The "superior alternative" is just a black box.
It's a black box that happens to meet the business needs of most organizations I have worked for. Linux has not. So, at least as far as usability is concerned, it is a superior alternative. MacOS is even superior from an administration perspective. Linux is good for servers, and that's it. You can build a linux system and then let it happily chortle away for years, even decades -- as long as you don't change anything. Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.
The registry is just crap and you're a moron for even bringing it up in this context.
You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through/etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.
"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here.
You haven't done software deployment, have you? There's a lot more to it than "replacing one version of an app with another". Applications have dependancies. These dependancies need to be validated, otherwise your copy-paste of a new application could result in a massive shit storm. Especially when you do it 140,000 times at a go.
If you ignore the package manager, you can install what you want.
Umm, no. If an application has been dynamically-linked to a given library, and you upgrade that library and one of the changes is the behavior of a function that application relies on, you can get all kinds of problems from buffer overflows to math errors and all other manner of fail because the application expects one thing and the library delivers something else.
This is the crux of "dll hell"; Multiple versions of a library. And not all of them are even developed by the same group. You can do dll injection, so that when you make a call to one dll, it's intercepted and replaced with something else. A great many exploits work on this functionality. A uniform interface for loading shared libraries, checking versioning and capabilities, etc., would resolve most of these problems and that's what Microsoft has been trying to move towards for years. Linux, meanwhile, has done nothing to address the issue, because malware authors have largely ignored Linux. But god help us all if the "day of the linux desktop" arrives, because we will be well and truly f*cked because of this design oversight.
Linux has had versioned shared libraries for ever.
That's nice. But I was talking about library management.
Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained.
Hi. Developer here. No, no it is not. Pain in the ass is thunking, handlers that silently disconnect from message pumps, calls to win32 that are "unmanaged" and so often lead to memory leaks even when you diligently try to do garbage collection, undocumented exceptions that are thrown by system calls that even the debugger blanches at, and endless layers of class and interfaces nine levels deep, many of which only document the public methods and tell you nothing else. The registry though? The registry is stupid easy. If you think that's a pain in the ass, you fail as a programmer. Turn in your badge.
Getting rid of the registry was a huge selling point for Windows 8,
So was the 'Metro' interface. And I don't see many people around here talking about how great Windows 8 is going to be -- everyone says it's going to be a three coiled turd. And this is what you use to advance your argument?
I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking.
There's no such thing as 'virii' and I don't think you know what a honey pot is. But perhaps you mean it's a rich repository of system and application settings that could be exploited by malicious people? Yes, that is correct. But then, scanning down the C: for a list of filenames can do that too. The registry has a rich set of access controls; Your lack of familiarity with other security concepts suggests you probably didn't know that.
Linux DOES INDEED have a system for library control, its called pkg_config and it works very well.
A tool used to assist in compiling is not a "library control" tool dude. It's main job is to tell whether a library is installed or not, what version it is, and where it is located. It doesn't do much else. It most certainly does not have any management functions.
Its not my problem if developers are too lazy to use it.
*facepalm* Who wrote the applications you're using right now? Are you sure their "lazyness" isn't your problem?
90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak.
That whooshing sound is the point flying over your head. 100% of windows applications have to go through the kernel to load dlls, and so it presents a standardized interface for doing so. Linux does not have this. Whether it's 90% of linux apps, or 99%, the lack of a standard means you, the developer, have to guess, pray, or assume, things about the environment. You can't rely on it.
I do quite well with Linux, thank you.
That's nice. I'm a neo-pagan who dances around poles naked, and it works quite well for me. But I'm not going to suggest it's for everyone, or that there aren't occasional problems in going "sky clad" in a public place. The police, for example, aren't as understanding as one might hope.
Sure, if you call 'ldconfig' "a half dozen different methods"
Does ldconfig allow for different versions of the same library to be requested by the application? Does ldconfig warn you when a dependancy isn't met? Does it allow per-application flags to override global settings?
And this class, is why we use explicit type casting and do sanity checks (checking limits) prior to processing. Now, if you'll look on your screens, you'll see another example of this. Here is a failed mission to Mars, caused because the wrong unit of measurement was put into the computer, a problem caused by the lack of the human brain's compiler to make use of any data type except 'variant' and 'object'... So, what have we learned?
Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.
That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell. The average linux installation has thousands of libraries. And they're all referenced and indexed using a half dozen different methods from files in/etc to compile-time kernel flags, etc.
Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc/scannow" at the command prompt.
Linux doesn't even have that much. It's a crap shoot as to which library version your executable will load. That's why adding 'beta' versions to the mix isn't easy: You could blow up your entire installation, so usually, beta releases are 'static' linked. I don't know why the kernel devs haven't addressed this problem.
Isn't '60-90 days of retraining' about the same as what you get for failing a class in high school and getting forced to take summer classes if you want to graduate?
True, but 60-90 days of focusing on material by a competent and mature adult will result in much better information retention than 60-90 days by a teenager whose hormones are busy staring at the sexual features of half the class, and their attitude is that what they're doing is a massive waste of time.
I learned the entire C programming language in less time than that; But I dedicated and motivated myself towards doing it. And it wasn't even "full time"... I just picked away at it, an hour here, an hour there. Nowadays I can absorb entire books worth of reference material in days. In 90 days, I could memorize everything there is to know about nuclear launches. Hell, I could probably build the damn rockets in that amount of time.
Why do we need yet another packaging standard? Isn't the whole point of open source to take good ideas and merge them together? So why then, do we see divergence like this so much more than convergence? Sigh. I suspect the reasons for this are political rather than technical; The main failing of open source as a community is that while the source is open, the politics are messy and it results in dozens of incompatible "open" standards, protocols, etc. We bitch and moan about closed source protocols and having to reverse-engineer everything, which is a massive waste of effort because we're duplicating previous work... and then we're busy doing it to ourselves.:(
I think you missed my point. I wasn't saying it was a safety issue, merely that no matter how high the stakes and how hard you try these things still happen.
Which is, frankly, a pointless point to make.
The USAF is, as you say, the gold standard. Civilian nuclear power is considerably less motivated and less well funded, with less oversight. That's why I take issue with the "oh if we just put better people in charge" brigade, and their friends in the "we can make it idiot proof" troop.
No, but you can add auditing and process controls to manage and reduce the problems to a very small percentage. Which is what the USAF has done, and done well. This isn't evidence of a failure in process, but rather a validation of it. And I didn't say Chair Force is the gold standard...
The weak link is always humans. The USAF had the best of intentions, was well funded and had oversight. Even so this was allowed to happen. At least they caught it.
Back up. If you look more closely, even a 'D' rating doesn't mean there was ever any danger of an accidental nuclear release, or lost/misplaced inventory, etc. This relates specifically and only to combat-readiness. These are the guys that sit in a room for days, hours, weeks at a go, with nothing to do but wait for the red lights and klaxxon alarms that say WW3 just started. They got a poor review because they were too slow in their reaction times, amongst other things as it relates to launch readiness.
This is the same thing that every military unit, in every branch, deals with sooner or later. Everyone's performance slips sooner or later, even if you're special forces. That's why these audits are done, everywhere, all the time. It's routine, and these reviews are part of everybody's service file. A poor review doesn't even necessarily mean you're going to lose out on a promotion opportunity in the long run. People are benched for retraining all the time. Mind you, the first step is usually additional training in situ, but given the seriousness of their job, I can understand skipping that.
But let's be clear: This is the military performing as expected. This is a routine thing, and it's only making the news because it involves nuclear weapons. If it happened anywhere else, it'd be a non-event.
You are saying that most IT departments are incompetent.
No, he's saying the budget for IT is very limited, and they don't want to invest in re-development, testing, and deployment. IT is viewed by most companies as a cost center. It's a "necessary evil" in the business process, and this is what managers are taught in schools across the country.
Why are there 15 different apps that are coded to a specific web browser version? A decent IT department would stop that.
You make it sound like the 'IT department' is somehow all-encompassing and all-knowing, and everyone is on the same page. Anyone who's worked more than a few months in this field knows that there's no such thing as an 'IT department'. There are many departments, many teams, all doing 'IT' things. Those departments sometimes work at cross-purposes, there's politics, communication barriers, etc. It's called bureauacracy and you quickly learn overcoming it takes more time than actually working with the technology. A single change to a server can take months of meetings, change requests, and may eventually be shot down by someone who's overworked and has more important things to do (to them anyway!), and so it gets rejected.
here would be one or two apps, and they would be more genericized, and maintained by a trained IT staff, not built by a secretary who knows some macros, or an engineer who built an app because "how hard can it be?".
Remember what I just said about bureauacracy? Sometimes it's just too damn hard to overcome interdepartmental politics and red tape and people roll their own solutions to get the job done. Is this the mythical 'IT Department's' job to smooth over every ruffled feather, fix every political tug of war? No. You work with the tools you're given, and you support what's handed to you; Because bitching will get you fired, and silently suffering will get you a glowing reference to move to another department or company where you'll get to suffer over a brand new set of design screwups and political crap. That's the difference between business reality and the business fiction you learn about in CSci and are trying to apply here.
The 15 apps generally come about because the IT department sucks. Then the IT department blames the users or budget makers for why the technology is broken.
In my experience, IT doesn't cast blame about, they're the ones being blamed because of this magical thinking that IT can just sprinkle magic fairy dust over complex and intractable political and business problems. Most of what I do in IT has nothing to do with computers; It is about the people.
The technology is stupid easy for me. Getting people to get the hell out of my way so I can do something with it, well... that's the rub.
The comparison should be made to Adobe CS6 Master Collection which is going for $2,100 on Amazon right now, not the smaller package of CS6 goes for $403.99. Adobe also announced the monthly cost for a single app will be $10/mo. for the first year, not the current $19.99/mo. Similarly, if you are an existing CS3 or higher owner, you can get the first year of everything for $39.99/mo. for the first year. Now I'm not saying whether this is a good or bad change, just pointing out that the summary's numbers aren't accurate.
Yes, and it omits an important number: People who are going to run away screaming from the idea of paying a monthly subscription fee and will turn to software piracy instead. Adobe is basically walling off the consumer market and then pouring concrete over it to kill it off, while telling it's corporate buyers that subscriptions are the way to go. Well, businesses don't care... it's just another line item to them. Of course they'll sign on.
And so it goes that Adobe becomes the enemy of self-employed graphic designers everywhere, attempting to destroy the artist who's barely scraping by.
This is what cloud computing is all about. It's not about providing a service to customers that's better than what they can get at their own desktops.
No, it is not. Cloud computing is things like Amazon's EC2 cloud; Which provides people who host content on the internet the valuable service of being able to add extra capacity on demand. It eliminates the slashdot effect on websites. It's also useful for a variety of other functions, like video encoding/decoding, load balancing, etc. Cloud computing is a Good Thing.
You've confused cloud computing with profiteering asshat corporations who are using it to effectively create a new kind of DRM. And like all forms of DRM, it isn't wanted, causes a wide range of problems, and screws over the paying customers. Which, from the article summary, is pretty much what everyone's predicting will happen.
Your point is on the processing and analytics side of the equation. I don't disagree with that assessment at all. I disagree that the capture and storage of the information isn't feasible; I firmly believe that it is. But the data would be largely useless without independent investigation using other data sources to locate useful information within this morass of information. Even the simplest keyword searches and lookups would take staggering amounts of computational power. You'd have to know where, what, and when, to extract useful data.
In spite of these difficulties, I can see our government attempting something this boneheaded. They've done stupider things; But I stand by what I said: You could build the necessary infrastructure to capture and store most of the internet's traffic for a short period of time. Making more than the most primitive queries against it though would be... well... let's just say I'll bring the popcorn if you bring the beer.
Not a chance on earth considering most of those people have qualifications that have nothing to do with IT work.
True story. There's a very finite supply of people with security clearances and the technical know-how to build, let alone maintain, this infrastructure.
never doubted that, but it isn't going to be close to what would be required to monitor every citizen and all of their communications. When the East Germans were doing this kind of thing they had a significant number of their population involved in spying on their population. It's a logistical issue that you can't get around, you have to have people to process all of the data.
In signals intelligence (SIGINT), processing and analyzing is 95% of the work. Capturing the data and storing it is not the problem, and never has been. Turning it into useful and actionable intelligence... to put it in perspective: We still have old decrypted communications from WWII that have never been read. Even back then, the problem of processing and analyzing the data greatly eclipsed the relatively manageable problem of capturing and storing it.
Legal shield doesn't change logistical practicalities from being an issue. I don't care how much cover you have, you still have to actually process everything and that takes more resources than are available.
Again, total agreement. We just don't have the tools or capability to sift through that much data for every piece of relevant information... we can use algorithms to organize it, to search for key words, to do probability analysis, but at the end of the day, a flesh and blood person has to look at it and decide if it's valuable. If we captured all the data transmitted on the internet for just a day, then stopped... I expect it would take all six plus billion people looking over it for months, even years, to distill it.
I was addressing the logistical practicalities of the claims, not the constitutional issues. You'll find I'm a strong Constitutional rights advocate, however that is different from whether or not the claims are actually possible. There is a world of difference between doing a given thing to some people some of the time and doing it to all of the people all of the time.
Right. As engineers, our job is limited to determining feasibility and implimentation. The discussion of the ethical, legal, and moral implications of the work is a separate (but no less important!) matter. Data collection is feasible, no doubt about it. Data processing and analysis... forget it.
We're 50 years from having the tools and processes needed to sift through, rank, and analyze network traffic and condense it into useful, actionable, and timely intelligence. At best, this initiative will simply allow us to look at the traffic history of a person of interest retrospectively; But we still have to rely on conventional investigative methods to find that person.
I'm not saying the logistical problems aren't difficult. I'm saying they are achieveable using today's technology, and within the budget of the US government to impliment. I think that's amply demonstrated here -- your own example, Cleversafe, will have a 10 exabyte array and 4.5 million disks. In 2010, 680 million disks were produced; Doubtless this number has gone up since then. Production capacity isn't a problem, land isn't a problem, electricity isn't a problem.
The government can do what this guy is claiming. Whether they have done it is another question entirely. All we're doing is placing the data point within the realm of possible.
Slashdot Mirror
Some of us have actually worked in environments like that.
You know, as much as I'd love to zip-thud and reveal my realworld identity and confirm that not only am I telling the truth, but I can provide specific examples, I am bound by an NDA and company policy that prohibits me from disclosing who I work for on social media.
I stand by what I said; The wide variety of linux distributions, software versions, differing packaging applications, etc., makes patch management and software deployment a nightmare. Every place that I have worked at where linux was used, has experienced major logistical headaches. Part of this is due to a lack of labor resources that are adequately trained in Linux, but a lot of it is that there aren't any enterprise-grade tools to make it easy. Most companies that support a lot of linux systems have rolled their own deployment infrastructure and have tried to standardize on one specific distribution to limit the amount of testing and validation needed.
Professionally, I can't recommend linux for anything other than servers and embedded solutions where the systems will run for years without being overhauled and that the only security patches to be applied will be for public-facing services.
That's just the reality of the industry. I have no attachment to Microsoft products; I've used MacOS, Linux, Windows... along with a variety of other now-defunct platforms like OS/2 Warp, BeOS, even CP/M. I'm "agnostic" about operating systems. My job as an IT professional is to facilitate the business process using the tools and resources given to me.
No. With SSD caching you get all the capacity of rotating disks with > 80% of the speed of SSDs.
That is not the worst of boths worlds. It is the best of one and most of the other.
No; You can achieve that with a separate SSD and a mechanical drive; That's what most people are doing now anyway.
By putting the two together, what you're basically getting is a mechanical drive with a massively large cache. And because you now have two drives married behind a single logical interface, you've decreased the life expectancy further -- if either fails, it's a boat anchor.
Oooh, your a pagan... is that the sign that I'm supposed to take you seriously? Shillin' for Microsoft... they're recruiting from you freaks now eh?
And yet they mod me as the troll in this discussion...
The iSSD and mechanical drive connect to
I believe I speak for the majority here when I say.... D'ARGH! KILL IT WITH FIRE NOW! This is yet another pathetic attempt by WD to marry it's crappy line of mechanical drives to SSDs in order to stretch their relevance out a little bit longer and keep them from having to retool their assembly lines and such to produce SSDs exclusively. Weeeell, good for you guys. But as my father would say: "Shit or get off the pot." Either switch to SSDs, and eat the cost, or stick with mechanical drives because they're cheap. But don't waffle and try to do both; You're getting the worst of both worlds then.
That's not an unmitigated good however, especially if you want to make edits but not commit them until you're done. Unix gets it mostly right in that I can send a NOHUP to tell the other process to reload.
Look, all I'm saying is that as far as ease of use, Linux fails here. I'm not saying linux can't perform well, or that it doesn't get the job done, etc., etc. What I am saying is that it's way of organizing configuration options is about thirty years old. Newer things have come along since, with clear advantages. Do they have disadvantages of their own? Of course.
But linux would benefit enormously from advancing to at least a central repository for application and operating system settings. If it's feeling particularly daring, it could even look at what Microsoft has done with .net assemblies and COM architecture. But, you know, baby steps...
You are a completely ignorant moron not really worth responding to. You are a very incompetent troll.
Yet I make way more money than you could even dream of doing network administration for a Fortune 100 business with over 150,000 workstations. Every night, I push out a half-dozen new applications, patches, and OS installs. Yes, I must be a troll... because I disagreed with your religious persuasions and am making an argument based on facts widely supported by market research and years of professional experience... whereas you're busy emoting on religious furvor.
In other words you're unemployed and living in your mother's basement. Your weak attempts at bluster impresses NO ONE here.
I think you're referring to yourself here, buddy. I'm going out this weekend to buy a new car...
You have no real clue abut Linux or corporate computing.
I know what technologies are in use at over a dozen Fortune 100 companies, and I'm familiar with them. And you know what -- none of them are looking for a boat load of linux administrators. There are reasons for this, whether you want to believe them or not.
As far as "just works" goes. Nothing that MacOS or WinDOS has can touch a Linux package manager.
SCCM: I push a button. 140,000 machines get updated with the next security patch. I get a nice report showing any failures, and pass this on to my remediation team to follow up on.
Linux: I push a button. Then I push a few more buttons. Then I puzzle over /var/log/debug ... then I recompile the kernel. Then I try deploying the kernel to a few other workstations. Then I find out that some of the modules that I thought weren't needed, were. I recompile the kernel again. Now I deploy the kernel and updated application. About half of the boxes stop booting up. I spend the next few hours paging data centers to reboot them and what special lines to enter into the "boot:" prompt to get it working again. Finally, I get the kernel and application deployed. The application crashes because it expected libc6 instead of libc5. At the end of all of this, I write a custom script to generate a report for me telling me which workstations got installed, which didn't, and if so, how they failed. I write it in Perl, because... Perl. A week later, the application is patched and the phone has stopped ringing from angry users. I open up my inbox... It's another request for a patch. I open my desk drawer, take out the gun, and shoot myself in the head.
Why on earth would I want to cram everything into a central repository?
This is a question that's been asked and answered a great many times, if you care to google it. I won't bother going into all of the benefits over centralization... but the biggest one is concurrently running applications: A change in the registry means the applications that access that key get the new value in real time. A file doesn't necessarily do that; Especially if it's been locked for writing.
Does ldconfig allow for different versions of the same library to be requested by the application?
Yes.
Can you please point out which setting in the man page allows you to set this, oh great wizard of Linux? Because I think you're just being a contrarian right now, and haven't actually read the damn page.
Better than that. You as a user can see what libraries are loaded from where and which ones are missing precisely.
Again, read the man page. You can specify which directories it uses to build its cache. That's it. There's no "precision" in that; And if you think I'm going to grep a few thousand lines of output to figure out which library it matched first, you've clearly spent too much time as a user and not enough time as a system administrator. I want something that just works... not having to screw around with a dozen /etc/ config files and another half dozen commands to suss out what went wrong everytime I upgrade a library or application.
The "superior alternative" is just a black box.
It's a black box that happens to meet the business needs of most organizations I have worked for. Linux has not. So, at least as far as usability is concerned, it is a superior alternative. MacOS is even superior from an administration perspective. Linux is good for servers, and that's it. You can build a linux system and then let it happily chortle away for years, even decades -- as long as you don't change anything. Keeping hundreds of linux boxes up to date and patched is a fucking nightmare.
That 2^31 gold ought to be enough for anybody?
Gryfindor loses 50 points.
The registry is just crap and you're a moron for even bringing it up in this context.
You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through /etc 's mass of files to do the same thing. Linux is still rocking the equivalent of ".ini" files, and yeah -- it is primitive. And I'm not a moron for bringing it up, you're a moron for not seeing that sometimes, your religion of choice, could benefit from looking outside of itself and seeing that other developers have done something better.
"DLL hell" has squat to do with it. The package manager is going to want to replace one version of an app with another. That is the only real problem here.
You haven't done software deployment, have you? There's a lot more to it than "replacing one version of an app with another". Applications have dependancies. These dependancies need to be validated, otherwise your copy-paste of a new application could result in a massive shit storm. Especially when you do it 140,000 times at a go.
If you ignore the package manager, you can install what you want.
Umm, no. If an application has been dynamically-linked to a given library, and you upgrade that library and one of the changes is the behavior of a function that application relies on, you can get all kinds of problems from buffer overflows to math errors and all other manner of fail because the application expects one thing and the library delivers something else.
This is the crux of "dll hell"; Multiple versions of a library. And not all of them are even developed by the same group. You can do dll injection, so that when you make a call to one dll, it's intercepted and replaced with something else. A great many exploits work on this functionality. A uniform interface for loading shared libraries, checking versioning and capabilities, etc., would resolve most of these problems and that's what Microsoft has been trying to move towards for years. Linux, meanwhile, has done nothing to address the issue, because malware authors have largely ignored Linux. But god help us all if the "day of the linux desktop" arrives, because we will be well and truly f*cked because of this design oversight.
Linux has had versioned shared libraries for ever.
That's nice. But I was talking about library management.
Um, the MS registry is a huge pain in the butt for developers and M$ knows it, but they can't get rid of it becuase its too ingrained.
Hi. Developer here. No, no it is not. Pain in the ass is thunking, handlers that silently disconnect from message pumps, calls to win32 that are "unmanaged" and so often lead to memory leaks even when you diligently try to do garbage collection, undocumented exceptions that are thrown by system calls that even the debugger blanches at, and endless layers of class and interfaces nine levels deep, many of which only document the public methods and tell you nothing else. The registry though? The registry is stupid easy. If you think that's a pain in the ass, you fail as a programmer. Turn in your badge.
Getting rid of the registry was a huge selling point for Windows 8,
So was the 'Metro' interface. And I don't see many people around here talking about how great Windows 8 is going to be -- everyone says it's going to be a three coiled turd. And this is what you use to advance your argument?
I dare you to ask me why... if you don't realize its a huge honey pot for virii and hackers you have no business even asking.
There's no such thing as 'virii' and I don't think you know what a honey pot is. But perhaps you mean it's a rich repository of system and application settings that could be exploited by malicious people? Yes, that is correct. But then, scanning down the C: for a list of filenames can do that too. The registry has a rich set of access controls; Your lack of familiarity with other security concepts suggests you probably didn't know that.
Linux DOES INDEED have a system for library control, its called pkg_config and it works very well.
A tool used to assist in compiling is not a "library control" tool dude. It's main job is to tell whether a library is installed or not, what version it is, and where it is located. It doesn't do much else. It most certainly does not have any management functions.
Its not my problem if developers are too lazy to use it.
*facepalm* Who wrote the applications you're using right now? Are you sure their "lazyness" isn't your problem?
90% of linux apps I've ever envountered use it, so don't come whining to me there's no soluton this lib hell of which you speak.
That whooshing sound is the point flying over your head. 100% of windows applications have to go through the kernel to load dlls, and so it presents a standardized interface for doing so. Linux does not have this. Whether it's 90% of linux apps, or 99%, the lack of a standard means you, the developer, have to guess, pray, or assume, things about the environment. You can't rely on it.
I do quite well with Linux, thank you.
That's nice. I'm a neo-pagan who dances around poles naked, and it works quite well for me. But I'm not going to suggest it's for everyone, or that there aren't occasional problems in going "sky clad" in a public place. The police, for example, aren't as understanding as one might hope.
Sure, if you call 'ldconfig' "a half dozen different methods"
Does ldconfig allow for different versions of the same library to be requested by the application? Does ldconfig warn you when a dependancy isn't met? Does it allow per-application flags to override global settings?
Nope.
And this class, is why we use explicit type casting and do sanity checks (checking limits) prior to processing. Now, if you'll look on your screens, you'll see another example of this. Here is a failed mission to Mars, caused because the wrong unit of measurement was put into the computer, a problem caused by the lack of the human brain's compiler to make use of any data type except 'variant' and 'object'... So, what have we learned?
Would it allow users to install multiple versions of the same application from packages? One of my gripes with Linux is that it's not easy to test new or beta versions of software since there is no easy way to install from packages alongside the existing (stable) version. Yes, I know that I could build the app from source, but that can be quite a hassle sometimes.
That's because Linux suffers from a similar problem that Windows 95/98, and XP to a lesser extent did: DLL hell. The average linux installation has thousands of libraries. And they're all referenced and indexed using a half dozen different methods from files in /etc to compile-time kernel flags, etc.
Microsoft solved this (partially) using a centralized registry and integrated it into the operating system. They've tried to add integrity-checking and what-not so that critical DLLs can be reverted in place... a primitive version-control system you can access by running "sfc /scannow" at the command prompt.
Linux doesn't even have that much. It's a crap shoot as to which library version your executable will load. That's why adding 'beta' versions to the mix isn't easy: You could blow up your entire installation, so usually, beta releases are 'static' linked. I don't know why the kernel devs haven't addressed this problem.
Isn't '60-90 days of retraining' about the same as what you get for failing a class in high school and getting forced to take summer classes if you want to graduate?
True, but 60-90 days of focusing on material by a competent and mature adult will result in much better information retention than 60-90 days by a teenager whose hormones are busy staring at the sexual features of half the class, and their attitude is that what they're doing is a massive waste of time.
I learned the entire C programming language in less time than that; But I dedicated and motivated myself towards doing it. And it wasn't even "full time"... I just picked away at it, an hour here, an hour there. Nowadays I can absorb entire books worth of reference material in days. In 90 days, I could memorize everything there is to know about nuclear launches. Hell, I could probably build the damn rockets in that amount of time.
Focus. It's everything.
Why do we need yet another packaging standard? Isn't the whole point of open source to take good ideas and merge them together? So why then, do we see divergence like this so much more than convergence? Sigh. I suspect the reasons for this are political rather than technical; The main failing of open source as a community is that while the source is open, the politics are messy and it results in dozens of incompatible "open" standards, protocols, etc. We bitch and moan about closed source protocols and having to reverse-engineer everything, which is a massive waste of effort because we're duplicating previous work... and then we're busy doing it to ourselves. :(
I think you missed my point. I wasn't saying it was a safety issue, merely that no matter how high the stakes and how hard you try these things still happen.
Which is, frankly, a pointless point to make.
The USAF is, as you say, the gold standard. Civilian nuclear power is considerably less motivated and less well funded, with less oversight. That's why I take issue with the "oh if we just put better people in charge" brigade, and their friends in the "we can make it idiot proof" troop.
No, but you can add auditing and process controls to manage and reduce the problems to a very small percentage. Which is what the USAF has done, and done well. This isn't evidence of a failure in process, but rather a validation of it. And I didn't say Chair Force is the gold standard...
My vote is for the Marines. ;)
The weak link is always humans. The USAF had the best of intentions, was well funded and had oversight. Even so this was allowed to happen. At least they caught it.
Back up. If you look more closely, even a 'D' rating doesn't mean there was ever any danger of an accidental nuclear release, or lost/misplaced inventory, etc. This relates specifically and only to combat-readiness. These are the guys that sit in a room for days, hours, weeks at a go, with nothing to do but wait for the red lights and klaxxon alarms that say WW3 just started. They got a poor review because they were too slow in their reaction times, amongst other things as it relates to launch readiness.
This is the same thing that every military unit, in every branch, deals with sooner or later. Everyone's performance slips sooner or later, even if you're special forces. That's why these audits are done, everywhere, all the time. It's routine, and these reviews are part of everybody's service file. A poor review doesn't even necessarily mean you're going to lose out on a promotion opportunity in the long run. People are benched for retraining all the time. Mind you, the first step is usually additional training in situ, but given the seriousness of their job, I can understand skipping that.
But let's be clear: This is the military performing as expected. This is a routine thing, and it's only making the news because it involves nuclear weapons. If it happened anywhere else, it'd be a non-event.
You are saying that most IT departments are incompetent.
No, he's saying the budget for IT is very limited, and they don't want to invest in re-development, testing, and deployment. IT is viewed by most companies as a cost center. It's a "necessary evil" in the business process, and this is what managers are taught in schools across the country.
Why are there 15 different apps that are coded to a specific web browser version? A decent IT department would stop that.
You make it sound like the 'IT department' is somehow all-encompassing and all-knowing, and everyone is on the same page. Anyone who's worked more than a few months in this field knows that there's no such thing as an 'IT department'. There are many departments, many teams, all doing 'IT' things. Those departments sometimes work at cross-purposes, there's politics, communication barriers, etc. It's called bureauacracy and you quickly learn overcoming it takes more time than actually working with the technology. A single change to a server can take months of meetings, change requests, and may eventually be shot down by someone who's overworked and has more important things to do (to them anyway!), and so it gets rejected.
here would be one or two apps, and they would be more genericized, and maintained by a trained IT staff, not built by a secretary who knows some macros, or an engineer who built an app because "how hard can it be?".
Remember what I just said about bureauacracy? Sometimes it's just too damn hard to overcome interdepartmental politics and red tape and people roll their own solutions to get the job done. Is this the mythical 'IT Department's' job to smooth over every ruffled feather, fix every political tug of war? No. You work with the tools you're given, and you support what's handed to you; Because bitching will get you fired, and silently suffering will get you a glowing reference to move to another department or company where you'll get to suffer over a brand new set of design screwups and political crap. That's the difference between business reality and the business fiction you learn about in CSci and are trying to apply here.
The 15 apps generally come about because the IT department sucks. Then the IT department blames the users or budget makers for why the technology is broken.
In my experience, IT doesn't cast blame about, they're the ones being blamed because of this magical thinking that IT can just sprinkle magic fairy dust over complex and intractable political and business problems. Most of what I do in IT has nothing to do with computers; It is about the people.
The technology is stupid easy for me. Getting people to get the hell out of my way so I can do something with it, well... that's the rub.
The comparison should be made to Adobe CS6 Master Collection which is going for $2,100 on Amazon right now, not the smaller package of CS6 goes for $403.99. Adobe also announced the monthly cost for a single app will be $10/mo. for the first year, not the current $19.99/mo. Similarly, if you are an existing CS3 or higher owner, you can get the first year of everything for $39.99/mo. for the first year. Now I'm not saying whether this is a good or bad change, just pointing out that the summary's numbers aren't accurate.
Yes, and it omits an important number: People who are going to run away screaming from the idea of paying a monthly subscription fee and will turn to software piracy instead. Adobe is basically walling off the consumer market and then pouring concrete over it to kill it off, while telling it's corporate buyers that subscriptions are the way to go. Well, businesses don't care... it's just another line item to them. Of course they'll sign on.
And so it goes that Adobe becomes the enemy of self-employed graphic designers everywhere, attempting to destroy the artist who's barely scraping by.
This is what cloud computing is all about. It's not about providing a service to customers that's better than what they can get at their own desktops.
No, it is not. Cloud computing is things like Amazon's EC2 cloud; Which provides people who host content on the internet the valuable service of being able to add extra capacity on demand. It eliminates the slashdot effect on websites. It's also useful for a variety of other functions, like video encoding/decoding, load balancing, etc. Cloud computing is a Good Thing.
You've confused cloud computing with profiteering asshat corporations who are using it to effectively create a new kind of DRM. And like all forms of DRM, it isn't wanted, causes a wide range of problems, and screws over the paying customers. Which, from the article summary, is pretty much what everyone's predicting will happen.
Your point is on the processing and analytics side of the equation. I don't disagree with that assessment at all. I disagree that the capture and storage of the information isn't feasible; I firmly believe that it is. But the data would be largely useless without independent investigation using other data sources to locate useful information within this morass of information. Even the simplest keyword searches and lookups would take staggering amounts of computational power. You'd have to know where, what, and when, to extract useful data.
In spite of these difficulties, I can see our government attempting something this boneheaded. They've done stupider things; But I stand by what I said: You could build the necessary infrastructure to capture and store most of the internet's traffic for a short period of time. Making more than the most primitive queries against it though would be... well... let's just say I'll bring the popcorn if you bring the beer.
Not a chance on earth considering most of those people have qualifications that have nothing to do with IT work.
True story. There's a very finite supply of people with security clearances and the technical know-how to build, let alone maintain, this infrastructure.
never doubted that, but it isn't going to be close to what would be required to monitor every citizen and all of their communications. When the East Germans were doing this kind of thing they had a significant number of their population involved in spying on their population. It's a logistical issue that you can't get around, you have to have people to process all of the data.
In signals intelligence (SIGINT), processing and analyzing is 95% of the work. Capturing the data and storing it is not the problem, and never has been. Turning it into useful and actionable intelligence... to put it in perspective: We still have old decrypted communications from WWII that have never been read. Even back then, the problem of processing and analyzing the data greatly eclipsed the relatively manageable problem of capturing and storing it.
Legal shield doesn't change logistical practicalities from being an issue. I don't care how much cover you have, you still have to actually process everything and that takes more resources than are available.
Again, total agreement. We just don't have the tools or capability to sift through that much data for every piece of relevant information... we can use algorithms to organize it, to search for key words, to do probability analysis, but at the end of the day, a flesh and blood person has to look at it and decide if it's valuable. If we captured all the data transmitted on the internet for just a day, then stopped... I expect it would take all six plus billion people looking over it for months, even years, to distill it.
I was addressing the logistical practicalities of the claims, not the constitutional issues. You'll find I'm a strong Constitutional rights advocate, however that is different from whether or not the claims are actually possible. There is a world of difference between doing a given thing to some people some of the time and doing it to all of the people all of the time.
Right. As engineers, our job is limited to determining feasibility and implimentation. The discussion of the ethical, legal, and moral implications of the work is a separate (but no less important!) matter. Data collection is feasible, no doubt about it. Data processing and analysis... forget it.
We're 50 years from having the tools and processes needed to sift through, rank, and analyze network traffic and condense it into useful, actionable, and timely intelligence. At best, this initiative will simply allow us to look at the traffic history of a person of interest retrospectively; But we still have to rely on conventional investigative methods to find that person.
I'm not saying the logistical problems aren't difficult. I'm saying they are achieveable using today's technology, and within the budget of the US government to impliment. I think that's amply demonstrated here -- your own example, Cleversafe, will have a 10 exabyte array and 4.5 million disks. In 2010, 680 million disks were produced; Doubtless this number has gone up since then. Production capacity isn't a problem, land isn't a problem, electricity isn't a problem.
The government can do what this guy is claiming. Whether they have done it is another question entirely. All we're doing is placing the data point within the realm of possible.