Actually, the context for "fresh" is consistent acceptable taste. If properly stored, and MRE can last 7 years and still keep its same edible consistency. If you had to, you could probably eat MREs older than 7 years, they just won't taste right.
You're too paranoid. What gives MRE's its storage life is not a bath of chemicals; its a very simple technique. The food is sealed in airtight packets with residual oxygen is removed. The packets are sturdy metal alloy interiors with plastic exteriors. They don't leak, and are near impossible to unintentionally puncture. No oxygen in the packet, no oxygen can get in, food can't decompose.
Actually, you can partly blame the Enron debacle for this. IBM's accounting methods were similar. They just didn't abuse it to the level that Enron did. But you should not expect as many glowing earnings reports in the future.
Ah, as opposed to an actual financial services/trading company where you actually implemented something...
"And what were you using 4-6 years ago before your "n-tier web apps"?"
That was the client/server push. You know, Powerbuilder, Uniface, etc. It was quite a big thing, I'm surprised you didn't hear about it.
No, I was busy maintaining systems that worked. You know, Sun/Solaris, Sybase, Oracle. Not making pretty GUI clients for IIS/Microsoft SQL servers.
"Its that same 10yr backlog in software architecture comprehension that allows me to recognize.NET as a nebulous vaporware."
Yeah... so are 32 bit processors.
Well, every commercial PC put out right now are running 32 bit processors, but I have yet to see one working.NET service available over the Internet. Or a functioning workgroup that actually is used in a production environment. You know what those are, right?
Indeed a common reason given for organisations sticking with Windows is in-house applications. Can they point the finger at Microsoft when those fail???
The fact that you're asking this means I have to belabour the obvious.
1) You can't always get what you want off the shelf. In particular, a trading company is not going to be able to go to Microsoft or a consulting shop for transaction trading software for its brokers, or some other rarefied application. They have internal software development groups for that very purpose. 2) The key to success is to be able to control your own destiny. Yeah, bureaucracies like to have a finger to point at, but you'd be surprised how many mavericks lurking around who care more about making sure the problem can never arise. The military likes to work this way as well.
What does this have to do with linux? They take on the added support cost, because they save more money on not paying licenses per platfrom.
Isn't going from certainty of risk (see BSA) to the vague possibility of risk a good move?
Since the BSA is a strawman, one could say yes. But its not only about the percentage of risk, its managing the actual harm. There's legal expenses, then possible lawsuit awards, and it could be extremely disruptive to the company to redevelop the software without the offending code. Look at Arthur Anderson; they were going to make lots of money and keep a client by risking a little impropriety. Its not enough that the possibility of a problem is remote.
Weird, we moved away from that paradigm about 8-10 years ago when we started doing client/server. For the past 4 years we've been doing n-tier web apps.
And who's we? And what were you using 4-6 years ago before your "n-tier web apps"?
I'm curious, since you are about 10 years behind the times in terms of understanding software architecture, how is it you know so much about.NET?
I don't claim to know anything about.NET; its technology was not the issue when I said it was driving companies to Linux. Its existence basically means that previous M$ products (like NT and Win2K) will eventually be unsupported by M$, forcing companies to buy the new OS as a costly subscription product or convert to Linux platforms. Its that same 10yr backlog in software architecture comprehension that allows me to recognize.NET as a nebulous vaporware. But you go ahead, skip your medication, and enjoy your.NET la-la land.
(Thank you to the/.er who refuted the MSVC arguments; less typing for me...)
To imply otherwise is like implying that Linux is a better desktop for endusers.
I won't start a flamewar here but I do prefer Linux to Windows as a desktop. No religious thing, I just like it better.
I said, for endusers. You think you're a luser, that's your problem.
Wait a second here. FORTRAN is better than C for math. period. That's it. But noone uses FORTRAN for math anymore. You know why? They use Mathematica! Gone are the days when mathematicians were essentially programmers. Now-a-days, the math guys just hand equations to the programmers. Seems mathematicians prefer pretty GUIs too;-)
Anyone familiar with FORTRAN or the programming industry would know that FORTRAN is an engineering language. Its hasn't been popular with mathematicians for decades. But many engineering problems use a lot of math, and performance is critical. You're going to get better performance from FORTRAN code than C code if you're writing applications for SDI. Otherwise, everyone else is going to prefer using C/C++, because it better manipulates strings, is more widely known, can better express a programming problem in abstractions, and can afford to take the performance hit! The professor was correct in her statement.
I didn't mean to sound overly critical or pretenious,
You incorrectly assume that your professor is wrong, you imply she doesn't know what she's talking about, and then you use your gestalt of stupidity as a basis to make a prejudiced, sexist, and condenscending remark. (BTW, I'm sure as miniscule the representation of females in/., they should all be able to bitchslap your karma to zero.)
but I think it's pretty objective that most professors aren't experienced in the real world.
I disagree with that statement. Most of them are working on the side, or their research requires expression in a commercial product. But even if you're right, so what? CS professors' job is not to train you for the commercial world; its to produce new CS research. If you believe otherwise, you've been suckered in by the university and society.
Figure that modern programming has been around, what, a decade? So, one has to figure that it takes at least 8 years to obtain the proper degree. So that leaves 2 years of time to get experience prior to teaching? In reality, how many professors have just started teaching after spending the last ten years in the field? It's not a reflection on them, just on praticality.
Modern programming??? Computer Science existed before there was computers! Before computers, it was merely a mathematics field that dealt with finite computational problems. Programming concepts derived before the 90's are still valid and relevant, trust me.
Why don't you ask your professors about their professional experience??? Don't assume mommy and daddy took care of everything for them (like you?). Those that couldn't live off the 'rents had to work day jobs while pursuing their education, and I'm sure they chose programming over flipping burgers. And not every PhD could count on gov't research grants and fellowships. They had to work a couple of years in the real world, before they could put together enough of a stake to head back to academia.
Comp Sci is gonna take a couple decades before it matures as a science.
And what constitutes a mature science? I wonder how long before mathematics can be considered a science. CS will be mature long before you will.
You misunderstand the problem. Their concern is when they adopt some sort of "GPL"ed product that people later discover that its IP ownership is in question.
They could also have IP that they do not wish to relinquish which might become a problem if it depends on a GPLed component. But that is a separate issue, and not the major concern.
1) Hmmm, $100+ for an Win2K/XP license, $200+ for an Exceed license. Oh yeah, what a deal compared to Linux.
2) I've worked with Exceed. Too bad neither you or Hummingbird could resolve the problem one of my users had with the console failing to connect. No problems with Sun, Linux, or other clients. We figured it was hardware, but were never able to track down the problem. Not my problem either, since I was the UNIX admin.
And who is accountable when their in-house application has a bug which costs them millions? Duh, Merrill. Do you think they only operate financial systems that have been produced by other companies or consulting shops??? Who would be responsible if there is a bug in the Linux distribution that cost them millions? Duh, Merrill. With linux, you have the source code available to be corrected. The only drawback is having one less entity to point the finger at.
The accountability issue has nothing to do with finding someone to blame. They're only concerned with IP issues, and this is where moving to Linux can bite them in the ass. You don't have to pay lawyers to figure out whether using a commercial software product could expose them to an IP lawsuit.
Fat chance of that. IBM would outbid any attempt by Sun to acquire RH. IBM is using RH for some of its infrastructure/customer support. Sun's only motivation to acquire RH would be to kill it.
Read the article. Do you really think Merrill Lynch is revealing something here? Trust me, every major financial institution are doing some form of linux project, in order to evaluate the costs of migrating to the platform. And if Merrill is utilizing IBM consultants, the fact they are using linux would not be secret for long.
The reality is that most financial applications running off a database backend will be processed using UNIX (or mainframe). Its a hell of lot easier to display those remote windows to UNIX platforms than M$ platforms. And since stock broker/analysts do not require Counterstrike to run on their machines, I would imagine quite a few desktops will be replaced as well.
What is driving this actually Microsoft.NET and its licensing costs. With the recession this year, a lot of managers are looking to shine. Upper management may consist of assholes, but rarely are they actual idiots. Alot of them in the tech departments may even have been system admnistrators at some point in their lives. This is totally doable, and management knows it. The problem is risking their ass to make an implementation attempt.
An example where Joel Spolsky is dead on with his marketing philosophy. (If it works, its almost too high a cost to redo without a revolutionary advantage.)
The funny thing though is that I had a bit of a debate with the C++ professor as she seemed to think that a) XEmacs is better than GNU Emacs b) MSVC++ is better than both of them. Of course, she also thought that Fortran was better than C:) That's why women don't make good programmer;-) (j/k)
1) Haven't used xemacs enough to form an opinion.
2) MSVC++ is better than either (as an IDE). It comes with a built in debugger, a class browser, and little knickknacks like color formatting. To imply otherwise is like implying that Linux is a better desktop for endusers.
3) FORTRAN is better than C in non-text handling situations and in performance. A math oriented problem coded in FORTRAN by a sharp programmer will blow away a similar coded C program. (This is because of C's overhead, and math libraries in FORTRAN benefit from 50+ years of fine tuning.) It sounds like she will still be a better programmer than you.
My response to yEnc was basically to sit on my thumbs watching all the movies & tv shows go into a yEnc-encoded oblivion until you guys put out the yEnc compatible Pan. (...Like I was going to switch to a windoze newsreader... bah!) Only lost two weeks worth of TV and movies...
NO, you miss the point! yEnc flaws cannot be corrected and implemented in a week!!! It cannot be fixed right now! And 30 different individuals trying to implement what they think is wrong with yEnc gives you 30 incompatible news readers!
I am not advocating waiting a year for a better standard. I am not in favor of waiting for the MIME committee to define a new standard. I am against "forcing" users to use yEnc as is, right now. (And this is being "forced" by the media newsgroup posters. The yEnc author cannot force yEnc's adoption on USENET. But he is actively encouraging it, even though it will need to be trashed in a couple of months.) It will result in a lot of grief when the yEnc author puts together a revised protocol in a couple of months. You do not grasp the problems that will be created by adopting the flawed yEnc now.
Yes there's the problem of legacy software, but a protocol that's only been around for a few weeks or months can't have that much of a legacy.
But what if it takes a year before an "improved" standard comes about? Everyone starts jumping around, forcing the new standard down people's throats. Then these poor non-commercial coders have to drop what their doing and implement the new protocol (including interpretation, and debugging time). (The commercial programmers have to go through it too, but I have no sympathy for people who are being remunerated for it.) If they don't react, they risk losing their userbase because they are perceived as being slow with "critical" improvements.
Nixon's complaint has to do with the fact that its not a thoroughly thought out implementation of a standard. Its a kludge. Nixon feels is that it is so apparently flawed, it will need to be reimplemented with corrections. This will cause a lot of angst for developers and users to deal with flawed software, and frequently upgrading it. And for what? The benefits may not even be that spectacular.
Frequent changes to a program is no big deal. (What didn't work right, now does.) Frequent changes to a protocol is a disaster. The programs' problem is not limited to correctly implement the new standard; it needs to interpret and then "properly" deal with the previous version(s). After all, how is program supposed to figure out if its a yEnc v0.9a and a yEnc v.093x? yEnc doesn't embed that kind of information in its format. And will the Forte reader be able to properly decode yEnc encodings by Pan? That can only be certain when there is an unambiguous protocol definition....and then everyone needs to do the upgrade tango! This is the mess that Nixon (and others) would like to avoid.
The only programs that currently support yEnc are the ones whose maintainers react pretty fast to new developments, and those maintainers are likely to also quickly pick up any revisions/fixes to yEnc.
Interesting, but all this change is actually being driven by the posters, not the newsreader developers. I've seen this firsthand in the alt.binaries.multimedia.* groups I frequent. They replace the uuencoding phase with the yEnc, treating it like old-style uuencoded posts, and then send the nntp articles. If people want their movies or tv episodes (before they expire in 2 days), their only choice is a yEnc capable newsreader. I'm sure the newsreader maintainers would have been more than happy to wait for a better standard.
So the solution Nixon should be calling for is not a years-long bureaucratic standardization process that will get yEnc 1.3 entrenched while the standardization is happening. The solution is to fix yEnc's problems and release a new version as fast as possible, before the old version gets spread around too widely.
I agree; waiting for the MIME committee to releases a standard before implementing yEnc would be like waiting for the Federal Gov't to issue TCO standards before creating the first personal computer. The solution was for the media posters to pass on the current yEnc implementation. If the flaws were obvious enough to require reworking yEnc, then the public should wait for the better implementation. I can understand why Nixon would have reservations about implementing a MIME-like standard without the MIME committee's approval. But then yEnc should not try to implement a MIME compatible kludge, and Nixon should ditch the complaints of yEnc not being a MIME compatible standard.
If the site is properly designed, you'll probably survive, because the ventilation system is supposed to kick in after a couple of minutes to clear the halon. (But don't assume that is the case at your site.) What I'm wondering is whether blowing out the floor tiles is a "desired" feature of a Halon system. (Ours is supposed to do that, halon blasted out from the floor.) Still, as I recall, you would have to be worried about dying from the stuff long-term (cancer, emphysema)...
xBSD fell to the wayside because of its inferior "marketing", but its not because of "Buzzword Bingo".
A key to a sucessful open software effort is mindshare. That is what gets you driver X for your machine, and companies investing money to improve an aspect of the operating system.
xBSD, like Hurd, was around before Linux. But unlike Linux, it was not as open in terms of permitting changes to its kernel. This might have changed now, but I would guess that Linux had a 4 year head start in terms of openness of its development effort. This is what got Linux mindshare. xBSD license may also not be as attractive to some commercial developers, but I doubt this is what put xBSD in its more obscure status.
The key to a sucessful marketing effort its to get your product out there with a greater number of customers than your competition. This is what happened with Linux vs xBSD. If xBSD is to gain mindshare, it can only do it by being a demonstrably better product than Linux. This is usually a losing proposition in the marketing world.
As for myself, I went Linux over xBSD because I was certain Linux was going to "mutate" faster than the xBSD. At the time, it was more open, in terms of kernel developers and change process, so improvements were going to be incorporated more quickly than xBSD. I always knew that xBSD was better tested (it was deployed in the commercial environment years before Linux) and probably more secure. xBSD might be the better product if I was the owner of a webserver farm or some other internet based service. But since I am not the owner of such an enterprise, xBSD does not give me any feature which makes it better than Linux. It looks to be the case in the UNIX world. So unless Linux does something to kill its marketshare position, xBSD is always going to be an obscure, historical effort.
As for HURD, its a joke. Its performance will probably always be inferior to Linux and this is because of technical reasons. (Namely, that uKernels waste a lot of CPU time talking to itself every time it executes an operation, which results in a lot of context switches.) Don't get me wrong, I really like u-kernels from a design perspective. (It should allow for greater mutation than Linux.) But you have to work off its designed disadvantages with sharp, performance prioritized coding. MACH is a hippo of a u-kernel. HURD will have to replace it with something better before it can really move. (Wake me up when they replace MACH with L4, and L4 has a finished, working design.) HURD is technically inferior to Linux from a performance perspective, and its never going to get marketshare for that reason.
Re:New SPARC kit? Move along there's nothing to se
on
Linux 2.4.18 Released
·
· Score: 2
If the bloat of the newer Solaris OSs makes your old hardware perform like a beached whale, why not just run Solaris 2.6? Its still maintained and will run packages of its era. So what that the latest Oracle won't run (or run well) on it, or that your old machine won't execute 64 bit code? It wasn't meant to run the latest Oracle monster, and the hardware was never meant to run 64 bit code.
(Granted, running SPARC Linux may be more entertaining, and I still suspect it would run faster than any version of Solaris...)
You armchair CEO's are so feebleminded. Its pretty obvious that Sun would had to have sunk in a lot money to make Solaris a viable platform on Intel PCs, and that does not count the millions of dollars they would need to piss away to market Solaris for x86. Properly run (non-dotbomb) companies do not piss away their capital if they cannot reasonably expect a return on their investment.
Don't you know that Microsoft does not spend their money on implementing device drivers to their operating system? No, its hardware vendors that spend their money to make their hardware work on windoze! Picture the amount of money Sun would need to blow to either get some participation from vendors or the manhours to provide equivalent driver support that Microsoft gets for free. (Actually, the hardware vendors pay Microsoft for the privilege of incorporating their driver into the M$ OS.)
That's why Solaris for x86 was stillborn. Have you even tried installing Solaris on a PC??? Simply put, one piece of hardware outside of its miniscule sanctioned list, and you're screwed. The device may not work, and worse, sometimes the machine won't work either.
Sun Microsystems has the vision of a pre-surgical cataract patient, but this Dumbo (Solaris x86) was not going to fly. And yes, its too bad. What they should have done was tried to become a linux reseller like Red Hat. It would have solved some strategic niches which Solaris for x86 was planned for and it would have cost them the same amount of money. They probably would have crushed Red Hat in marketing and had a chance of snacking on Microsoft lunch. Oh well.
Almost all technical staff I've worked with have been very productive and done good work, which I've seen a lot of slacking or just simply inept..
I'm sure your technical coworkers were productive and did good work, but that does not sell a product. That only makes a product which isn't moving. Perhaps the marketing & middle management types were more worthy of the axe, but their job is to make the company a profit. The tech's job is an abstract creation of product to sell.
Its not so weird. Hiring/firing of sales staff is not greatly affected by economic downturns. The reason is that a business's survival is based on making sales. If you fire someone who's job it is to sell, that's one less person available to keep your company alive. Even if there are people not selling, its blamed on the downturn, not the person's selling skills. Firing such a person then means you do not have an experienced body who can maximize your selling rate once the economy improves. Sales staff are less expensive to keep if they work on commission too. Layoffs in sales staff only occurs when there is confidence that the sales staff cannot possibly move product for a long period of time. Then you may want to improve the quarter's bottom line. Good sales managers hire/fire based on a performance curve; weed out the least productive regardless of the economic outlook.
Slashdot Mirror
Actually, the context for "fresh" is consistent acceptable taste. If properly stored, and MRE can last 7 years and still keep its same edible consistency. If you had to, you could probably eat MREs older than 7 years, they just won't taste right.
You're too paranoid. What gives MRE's its storage life is not a bath of chemicals; its a very simple technique. The food is sealed in airtight packets with residual oxygen is removed. The packets are sturdy metal alloy interiors with plastic exteriors. They don't leak, and are near impossible to unintentionally puncture. No oxygen in the packet, no oxygen can get in, food can't decompose.
Actually, you can partly blame the Enron debacle for this. IBM's accounting methods were similar. They just didn't abuse it to the level that Enron did. But you should not expect as many glowing earnings reports in the future.
Ah, as opposed to an actual financial services/trading company where you actually implemented something...
No, I was busy maintaining systems that worked. You know, Sun/Solaris, Sybase, Oracle. Not making pretty GUI clients for IIS/Microsoft SQL servers.
Well, every commercial PC put out right now are running 32 bit processors, but I have yet to see one working .NET service available over the Internet. Or a functioning workgroup that actually is used in a production environment. You know what those are, right?
Indeed a common reason given for organisations sticking with Windows is in-house applications. Can they point the finger at Microsoft when those fail???
The fact that you're asking this means I have to belabour the obvious.
1) You can't always get what you want off the shelf. In particular, a trading company is not going to be able to go to Microsoft or a consulting shop for transaction trading software for its brokers, or some other rarefied application. They have internal software development groups for that very purpose.
2) The key to success is to be able to control your own destiny. Yeah, bureaucracies like to have a finger to point at, but you'd be surprised how many mavericks lurking around who care more about making sure the problem can never arise. The military likes to work this way as well.
What does this have to do with linux? They take on the added support cost, because they save more money on not paying licenses per platfrom.
Isn't going from certainty of risk (see BSA) to the vague possibility of risk a good move?
Since the BSA is a strawman, one could say yes. But its not only about the percentage of risk, its managing the actual harm. There's legal expenses, then possible lawsuit awards, and it could be extremely disruptive to the company to redevelop the software without the offending code. Look at Arthur Anderson; they were going to make lots of money and keep a client by risking a little impropriety. Its not enough that the possibility of a problem is remote.
I don't claim to know anything about .NET; its technology was not the issue when I said it was driving companies to Linux. Its existence basically means that previous M$ products (like NT and Win2K) will eventually be unsupported by M$, forcing companies to buy the new OS as a costly subscription product or convert to Linux platforms. Its that same 10yr backlog in software architecture comprehension that allows me to recognize .NET as a nebulous vaporware. But you go ahead, skip your medication, and enjoy your .NET la-la land.
(Thank you to the /.er who refuted the MSVC arguments; less typing for me...)
I said, for endusers. You think you're a luser, that's your problem.
Anyone familiar with FORTRAN or the programming industry would know that FORTRAN is an engineering language. Its hasn't been popular with mathematicians for decades. But many engineering problems use a lot of math, and performance is critical. You're going to get better performance from FORTRAN code than C code if you're writing applications for SDI. Otherwise, everyone else is going to prefer using C/C++, because it better manipulates strings, is more widely known, can better express a programming problem in abstractions, and can afford to take the performance hit! The professor was correct in her statement.
You incorrectly assume that your professor is wrong, you imply she doesn't know what she's talking about, and then you use your gestalt of stupidity as a basis to make a prejudiced, sexist, and condenscending remark. (BTW, I'm sure as miniscule the representation of females in /., they should all be able to bitchslap your karma to zero.)
I disagree with that statement. Most of them are working on the side, or their research requires expression in a commercial product. But even if you're right, so what? CS professors' job is not to train you for the commercial world; its to produce new CS research. If you believe otherwise, you've been suckered in by the university and society.
Modern programming??? Computer Science existed before there was computers! Before computers, it was merely a mathematics field that dealt with finite computational problems. Programming concepts derived before the 90's are still valid and relevant, trust me.
Why don't you ask your professors about their professional experience??? Don't assume mommy and daddy took care of everything for them (like you?). Those that couldn't live off the 'rents had to work day jobs while pursuing their education, and I'm sure they chose programming over flipping burgers. And not every PhD could count on gov't research grants and fellowships. They had to work a couple of years in the real world, before they could put together enough of a stake to head back to academia.
And what constitutes a mature science? I wonder how long before mathematics can be considered a science. CS will be mature long before you will.
You misunderstand the problem. Their concern is when they adopt some sort of "GPL"ed product that people later discover that its IP ownership is in question.
They could also have IP that they do not wish to relinquish which might become a problem if it depends on a GPLed component. But that is a separate issue, and not the major concern.
1) Hmmm, $100+ for an Win2K/XP license, $200+ for an Exceed license. Oh yeah, what a deal compared to Linux.
2) I've worked with Exceed. Too bad neither you or Hummingbird could resolve the problem one of my users had with the console failing to connect. No problems with Sun, Linux, or other clients. We figured it was hardware, but were never able to track down the problem. Not my problem either, since I was the UNIX admin.
And who is accountable when their in-house application has a bug which costs them millions? Duh, Merrill. Do you think they only operate financial systems that have been produced by other companies or consulting shops??? Who would be responsible if there is a bug in the Linux distribution that cost them millions? Duh, Merrill. With linux, you have the source code available to be corrected. The only drawback is having one less entity to point the finger at.
The accountability issue has nothing to do with finding someone to blame. They're only concerned with IP issues, and this is where moving to Linux can bite them in the ass. You don't have to pay lawyers to figure out whether using a commercial software product could expose them to an IP lawsuit.
Fat chance of that. IBM would outbid any attempt by Sun to acquire RH. IBM is using RH for some of its infrastructure/customer support. Sun's only motivation to acquire RH would be to kill it.
So how do you make those aliens go away?
Read the article. Do you really think Merrill Lynch is revealing something here? Trust me, every major financial institution are doing some form of linux project, in order to evaluate the costs of migrating to the platform. And if Merrill is utilizing IBM consultants, the fact they are using linux would not be secret for long.
The reality is that most financial applications running off a database backend will be processed using UNIX (or mainframe). Its a hell of lot easier to display those remote windows to UNIX platforms than M$ platforms. And since stock broker/analysts do not require Counterstrike to run on their machines, I would imagine quite a few desktops will be replaced as well.
What is driving this actually Microsoft .NET and its licensing costs. With the recession this year, a lot of managers are looking to shine. Upper management may consist of assholes, but rarely are they actual idiots. Alot of them in the tech departments may even have been system admnistrators at some point in their lives. This is totally doable, and management knows it. The problem is risking their ass to make an implementation attempt.
An example where Joel Spolsky is dead on with his marketing philosophy. (If it works, its almost too high a cost to redo without a revolutionary advantage.)
1) Haven't used xemacs enough to form an opinion.
2) MSVC++ is better than either (as an IDE). It comes with a built in debugger, a class browser, and little knickknacks like color formatting. To imply otherwise is like implying that Linux is a better desktop for endusers.
3) FORTRAN is better than C in non-text handling situations and in performance. A math oriented problem coded in FORTRAN by a sharp programmer will blow away a similar coded C program. (This is because of C's overhead, and math libraries in FORTRAN benefit from 50+ years of fine tuning.) It sounds like she will still be a better programmer than you.
BTW, kudos on the 0.11.2.90 release.
My response to yEnc was basically to sit on my thumbs watching all the movies & tv shows go into a yEnc-encoded oblivion until you guys put out the yEnc compatible Pan. (...Like I was going to switch to a windoze newsreader... bah!) Only lost two weeks worth of TV and movies...
NO, you miss the point! yEnc flaws cannot be corrected and implemented in a week!!! It cannot be fixed right now! And 30 different individuals trying to implement what they think is wrong with yEnc gives you 30 incompatible news readers!
I am not advocating waiting a year for a better standard. I am not in favor of waiting for the MIME committee to define a new standard. I am against "forcing" users to use yEnc as is, right now. (And this is being "forced" by the media newsgroup posters. The yEnc author cannot force yEnc's adoption on USENET. But he is actively encouraging it, even though it will need to be trashed in a couple of months.) It will result in a lot of grief when the yEnc author puts together a revised protocol in a couple of months. You do not grasp the problems that will be created by adopting the flawed yEnc now.
Yes there's the problem of legacy software, but a protocol that's only been around for a few weeks or months can't have that much of a legacy.
But what if it takes a year before an "improved" standard comes about? Everyone starts jumping around, forcing the new standard down people's throats. Then these poor non-commercial coders have to drop what their doing and implement the new protocol (including interpretation, and debugging time). (The commercial programmers have to go through it too, but I have no sympathy for people who are being remunerated for it.) If they don't react, they risk losing their userbase because they are perceived as being slow with "critical" improvements.
Nixon's complaint has to do with the fact that its not a thoroughly thought out implementation of a standard. Its a kludge. Nixon feels is that it is so apparently flawed, it will need to be reimplemented with corrections. This will cause a lot of angst for developers and users to deal with flawed software, and frequently upgrading it. And for what? The benefits may not even be that spectacular.
Frequent changes to a program is no big deal. (What didn't work right, now does.) Frequent changes to a protocol is a disaster. The programs' problem is not limited to correctly implement the new standard; it needs to interpret and then "properly" deal with the previous version(s). After all, how is program supposed to figure out if its a yEnc v0.9a and a yEnc v.093x? yEnc doesn't embed that kind of information in its format. And will the Forte reader be able to properly decode yEnc encodings by Pan? That can only be certain when there is an unambiguous protocol definition. ...and then everyone needs to do the upgrade tango! This is the mess that Nixon (and others) would like to avoid.
The only programs that currently support yEnc are the ones whose maintainers react pretty fast to new developments, and those maintainers are likely to also quickly pick up any revisions/fixes to yEnc.
Interesting, but all this change is actually being driven by the posters, not the newsreader developers. I've seen this firsthand in the alt.binaries.multimedia.* groups I frequent. They replace the uuencoding phase with the yEnc, treating it like old-style uuencoded posts, and then send the nntp articles. If people want their movies or tv episodes (before they expire in 2 days), their only choice is a yEnc capable newsreader. I'm sure the newsreader maintainers would have been more than happy to wait for a better standard.
So the solution Nixon should be calling for is not a years-long bureaucratic standardization process that will get yEnc 1.3 entrenched while the standardization is happening. The solution is to fix yEnc's problems and release a new version as fast as possible, before the old version gets spread around too widely.
I agree; waiting for the MIME committee to releases a standard before implementing yEnc would be like waiting for the Federal Gov't to issue TCO standards before creating the first personal computer. The solution was for the media posters to pass on the current yEnc implementation. If the flaws were obvious enough to require reworking yEnc, then the public should wait for the better implementation. I can understand why Nixon would have reservations about implementing a MIME-like standard without the MIME committee's approval. But then yEnc should not try to implement a MIME compatible kludge, and Nixon should ditch the complaints of yEnc not being a MIME compatible standard.
If the site is properly designed, you'll probably survive, because the ventilation system is supposed to kick in after a couple of minutes to clear the halon. (But don't assume that is the case at your site.) What I'm wondering is whether blowing out the floor tiles is a "desired" feature of a Halon system. (Ours is supposed to do that, halon blasted out from the floor.) Still, as I recall, you would have to be worried about dying from the stuff long-term (cancer, emphysema)
xBSD fell to the wayside because of its inferior "marketing", but its not because of "Buzzword Bingo".
A key to a sucessful open software effort is mindshare. That is what gets you driver X for your machine, and companies investing money to improve an aspect of the operating system.
xBSD, like Hurd, was around before Linux. But unlike Linux, it was not as open in terms of permitting changes to its kernel. This might have changed now , but I would guess that Linux had a 4 year head start in terms of openness of its development effort. This is what got Linux mindshare. xBSD license may also not be as attractive to some commercial developers, but I doubt this is what put xBSD in its more obscure status.
The key to a sucessful marketing effort its to get your product out there with a greater number of customers than your competition. This is what happened with Linux vs xBSD. If xBSD is to gain mindshare, it can only do it by being a demonstrably better product than Linux. This is usually a losing proposition in the marketing world.
As for myself, I went Linux over xBSD because I was certain Linux was going to "mutate" faster than the xBSD. At the time, it was more open, in terms of kernel developers and change process, so improvements were going to be incorporated more quickly than xBSD. I always knew that xBSD was better tested (it was deployed in the commercial environment years before Linux) and probably more secure. xBSD might be the better product if I was the owner of a webserver farm or some other internet based service. But since I am not the owner of such an enterprise, xBSD does not give me any feature which makes it better than Linux. It looks to be the case in the UNIX world. So unless Linux does something to kill its marketshare position, xBSD is always going to be an obscure, historical effort.
As for HURD, its a joke. Its performance will probably always be inferior to Linux and this is because of technical reasons. (Namely, that uKernels waste a lot of CPU time talking to itself every time it executes an operation, which results in a lot of context switches.) Don't get me wrong, I really like u-kernels from a design perspective. (It should allow for greater mutation than Linux.) But you have to work off its designed disadvantages with sharp, performance prioritized coding. MACH is a hippo of a u-kernel. HURD will have to replace it with something better before it can really move. (Wake me up when they replace MACH with L4, and L4 has a finished, working design.) HURD is technically inferior to Linux from a performance perspective, and its never going to get marketshare for that reason.
devil made me do it...
If the bloat of the newer Solaris OSs makes your old hardware perform like a beached whale, why not just run Solaris 2.6? Its still maintained and will run packages of its era. So what that the latest Oracle won't run (or run well) on it, or that your old machine won't execute 64 bit code? It wasn't meant to run the latest Oracle monster, and the hardware was never meant to run 64 bit code.
(Granted, running SPARC Linux may be more entertaining, and I still suspect it would run faster than any version of Solaris...)
You armchair CEO's are so feebleminded. Its pretty obvious that Sun would had to have sunk in a lot money to make Solaris a viable platform on Intel PCs, and that does not count the millions of dollars they would need to piss away to market Solaris for x86. Properly run (non-dotbomb) companies do not piss away their capital if they cannot reasonably expect a return on their investment.
Don't you know that Microsoft does not spend their money on implementing device drivers to their operating system? No, its hardware vendors that spend their money to make their hardware work on windoze! Picture the amount of money Sun would need to blow to either get some participation from vendors or the manhours to provide equivalent driver support that Microsoft gets for free. (Actually, the hardware vendors pay Microsoft for the privilege of incorporating their driver into the M$ OS.)
That's why Solaris for x86 was stillborn. Have you even tried installing Solaris on a PC??? Simply put, one piece of hardware outside of its miniscule sanctioned list, and you're screwed. The device may not work, and worse, sometimes the machine won't work either.
Sun Microsystems has the vision of a pre-surgical cataract patient, but this Dumbo (Solaris x86) was not going to fly. And yes, its too bad. What they should have done was tried to become a linux reseller like Red Hat. It would have solved some strategic niches which Solaris for x86 was planned for and it would have cost them the same amount of money. They probably would have crushed Red Hat in marketing and had a chance of snacking on Microsoft lunch. Oh well.
Almost all technical staff I've worked with have been very productive and done good work, which I've seen a lot of slacking or just simply inept..
I'm sure your technical coworkers were productive and did good work, but that does not sell a product. That only makes a product which isn't moving. Perhaps the marketing & middle management types were more worthy of the axe, but their job is to make the company a profit. The tech's job is an abstract creation of product to sell.
Its not so weird. Hiring/firing of sales staff is not greatly affected by economic downturns. The reason is that a business's survival is based on making sales. If you fire someone who's job it is to sell, that's one less person available to keep your company alive. Even if there are people not selling, its blamed on the downturn, not the person's selling skills. Firing such a person then means you do not have an experienced body who can maximize your selling rate once the economy improves. Sales staff are less expensive to keep if they work on commission too. Layoffs in sales staff only occurs when there is confidence that the sales staff cannot possibly move product for a long period of time. Then you may want to improve the quarter's bottom line. Good sales managers hire/fire based on a performance curve; weed out the least productive regardless of the economic outlook.