Re:Sun's hardware does run linux well
on
Sun-isms Debunked
·
· Score: 1
Agreed. I've found the most stable way to use an old Sun is to install Linux on it, rather than deal with the pain of accomodating a difficult to support and always out-of-date on core tools OS like Solaris.
If Solaris 10 is a departuture from their more closed models, that would be great.
No, they made it easier when they let someone steal all their source code last year, then used it as an excuse to delay their game release for a year while providing no significant changes in the security models of their software.
No, it doesn't help much. Domain keys, like Microsoft's SenderID, rely on the sender to purchase or generate a key, and on the recipient's client or their SMTP server to decrypt the public key. This is a significant computational load on the recipient: if it wasn't, there'd be no point because the keys would be easy to forge.
Expect this system to seriously bog down typical mail servers which already run at 20% or better of their available CPU capacity, especially if it gains any prevalence or is used for mailing lists for which email arrives for multiple users in big bundles.
Solaris doesn't ship with a compiler, hasn't for at least seven years. If you paid for their compiler and don't like it (sucker), use gcc.
That's right, you have to pay a significant chunk of cash to get their compiler. I didn't bother mentioning that part. But to take real speed a nd performance advantage of the Sun architectures, you need the Sun compilers.
Yeah, including display postscript was a real bastard move.
No, it was merely a miserable failure. The use of commercial proprietary toolset as the underlying architecture was doomed to failure, in a way that X11 and the other X architectures have not been.
They include open-source tools like that with Solaris 9. The tools have always been available elsewhere.
Yes, because people like me built them up from scratch and published our patches and packages. What in the heck do you think I wasted so much time doing dealing with Solaris but getting such tools ported over so they could be actually used in a large and mixed environment?
That is not Sun's fault. For that matter, try porting most of the stuff you find bundled with a Linux distro to any other platform... hell, just try porting all the tools you need to build it...
I have. I've been doing it for years. The GNU stuff is pretty easy to bring over, once you have a few basics installed. It gets far more difficult to do when you have to deal with Sun's traditionally closed source stuff, like NIS, their libc, and their graphical display tools.
Sorry, I came to Solaris from the SunOS world. I've administered a bunch of flavors of SunOS, Solaris, Linux, and other OS's. The "time to set up your environment" has traditionally been time wasted from my life, especially trying to repackage things. I found the best way to set up a stable server for basic mail or file server utilities with Sun hardware was to install Linux on it, at least a few years ago.
And you've apparently never dealt with the vagaries of transporting locally written X-Windows or video image handling tools from Sun to elsewhere. At least a few years ago, the Sun include files could be called multiple times and do different things because they didn't use an "I've already been called!" flag, and ifdef values would be changed by the time it got called the second time. That was extremely painful to deal with.
Go hit the universities, office, and R&D environments. Solaris is still used as server class machines, but the last place I worked deliberately suspended all work and development with Solaris years ago because the workstations were overpriced and non-competitive with what a PC running Linux could do: they just weren't worth it in the desktop machine market.
Administering Solaris has been, traditionally, as much work as administering 3 different Linux releases at the same time. The subtle distinctions between their various compilers, the oddness they did to X, and their refusal to replace their various shells and command line utilities like "compress" with the vastly superior open source tools like "gzip" meant that to do any real work, you had to spend a huge amount of time porting over your tools both ways. And porting Solaris code to the non-Solaris world is often quite difficult.
I hope this change encourages Sun to go the open source route on core utilities, and spend their development time on the kernel and the compiler. While their hardware has been interesting, I really feel that it's not going to be a big driver for them in the face of AMD's now stable and quite inexpensive 64-bit architectures, which is the market where Sun should have focused their hardware development for the last 5 years.
Yes, this works fine. Also, Fedora is quite nice about using the "yum" command to fetch the particular package you want and all its dependencies, or removing them, after your OS is installed.
The stripped down version is CD 1, which allows you to do a "minimal" install.
Fedora is a testbed for RedHat Enterprise Linux. As such, it tends to have a lot of cutting edge tools, which get tested and refined into things that are worth putting into RHEL. That's how RedHat justifies doing this completely "free" release but providing to consumer grade support.
The result is not bad. Patches are fast, feature additions are fast and furious, and they do seem to be listening to complaints in their bugzilla quite well and fixing them ASAP.
The bulk mail discounts are *huge*. The Post Office is kept afloat by junk mail: it's one of the federal offices that actually makes a profit, but it does so because bulk mail is very easy to process with all the bar code scanners and older bulk mail handling techniques.
If it weren't easy and cheap, far more of your mail at home would actually be worth reading rather than the 90% that most of us simply throw away.
Even if sentenced to 9 years (which is extraordinarily unlikely), he's unlikely to spend more than a year in jail. It's not a violent set of crimes, the US jails are overloaded with poor convicts on various drug charges, and he'd be extremely likely to be on parole. He's got the smarts and social skills to run a significantly sized business, the parole board is unlikely to hold him in jail a moment more than necessary.
It's called a "pink contract", a business contract with the clauses that normally forbid business like spamming carefully left out. They're quite common for struggling ISP's, which normally make sure the bandwidth is paid for up front.
agis.net did this for quite some time with Cyberpromo, until the crackers took their routers down and kept them down until Cyberpromo went offline. But it took almost 2 years to get people worked up enough that the crackers would do this.
There is no way in hell this guy is going to jail for nine years. Despite his blatant fraud, the Direct Marketing Association is lending him legal support lest precedents get set that will encumber their commercial spam and junk mail. The ISP that sold him the multiple T1's or T3's is doubtless going to help out in court as well, to avoid liability for their laxity in not acting against all the complaints.
Even Sanford Wallace, the king of spam at cyberpromo.com for some years, is already back in business after numerous court losses, which he normally handled by settling out of court before he could be convicted.
Expect a "stiff fine" at worst for this spammer, and for him to be back in business within six months.
That's really strange, because I never saw an arrest, prosecution, or even a formal accusation out of Valve software.
What I saw was a a lot of lies designed to keep investors off their back: "They used an Internet Explorer bug", which is possible but unlikely. Social engineering of one of their employees or guessing a trivial password are far more likely ways into a remotely secure network. "They only got a little bit of the source code", which was a blatant lie because pirated copies of Half-Life 2 turned up in Russia with newly dubbed voices. "We'll be slightly delayed", which was another lie because it took more than another year to get the game out.
Stealing your source code is no excuse for having such a late release date, unless the game was absolutely not ready for release and you used the theft as an excuse to do the sort of complete design and security work you should have done in the first place. Given Valve's and ATI's cooking of the video results in the ATI/Nvidia video card comparisons, I don't think you can trust Valve the company's claims about anything.
The games have been good: games are not designed by corporate boards. But public press announcements, release schedules, and cooked demos are.
From the dotcom era, it's easily 3 out of 4 entirely underwater. Owners of real stock, however, seem to have done better. They still have some value left, and even if the company was going completely under could recoup some small value by selling it.
VP's and their ilk often have extensive insider iniformation that allows them to sell off or buy hunks of stock before the "blackout period" immediately surrounding big business announcements. Sad, but true. It's how so many of them also know to retire or "move on in their career" and cash out their options, just before the big trouble hits the papers.
Sad, but true. I've actually seen a VP cover his ears and go "la-la-la-la, I can't hear you talk about this because I'm selling stock, la-la-la-la!" We had to actually go find another VP to discuss the very bad matter about to happen with, to get their approval to can a business partner.
Now, folks, notice the shell game this fellow just did. He succeeded in conflating ESPP and "employee pay over the minimum to get you is wasted" with stock options. These are each very, very distinct issues. The conflation and shell game are part and parcel of the stock sales game. The.sig is also nice hook to try and rope in some extra business from slashdotters who are convinced of the
Stock options at the typical employee level are betting your man-hours, your hard-work and time, against the increasing stock value of the company. They're also where companies hide money for executives: there's a fascinating set of income tax and reporting requirement laws that take effect when a CEO or other corporate officer makes over $1 million/year, that are frequently evaded by paying exceptional amounts of stock options that need not be reported to the stock holders.
It's a nasty world out there. Watch your backs.
No. Stock options are not stock. The company does not pay dividends, you cannot sell them at whim, and they're worth exactly nothing if the company value does not go up.
It actually makes it advantageous for the company to keep the stock value low, bump it high with some faked up announcement so the the VP's can sell their options at a fraudulent value quickly before the employees can blink, then step out or even quit before the fraud comes home.
Why do you think it's called "pump and dump"?
Re:My company still hands them out like TP
on
Employee Stock Options?
·
· Score: 2, Insightful
Bingo. STock options were a way to pay people in the future of the company: they were used to give wildly underpaid employees, and investors, something on paper. Unfortunately, they're only valuable when the company's stock value goes up.
Now look very carefully. The only people who can sell them when the company makes its IPO are VP's. The employees are prevented by lockout periods from selling them when they are most valuable, right after the IPO or when they have some value left, right before the company tanks. VP's, however, get to sell them with the insider knowledge that they're not supposed to use, and they get nice golden parachutes when the company tanks. In a few cases, the employees can get more value than the many man-hours they invested and the pay they didn't get to take the stock options instead. And in a few cases, people win big lottery options that are worth more than all the lottery tickets they personally bought.
But they're not a good investment idea for most of us who do the real work. In most cases, they're a place to hide money to pay off the highest level staff, in a way that the company doesn't have to show on their books and will never have to redeem except for those high level staff who can sell them when they have value.
Use yum. Make a copy of your yum.conf called yum.conf.update, and replace the $releasever everywhere with the number "3".
Then run "yum clean; yum -c yum.conf.update check-update" to pre-load the header files files, and "yum -c yum.conf.update yum; yum -c yum.conf.update update" to actuall do the updates.
The new version of yum has some nice pre-downloading features, which is why I recommend updating it first.
Me too. I want them to backport clear kernel fixes and driver additions to the older kernel, rather than publishing a fresh-off-the-presses and not yet stable kernel and forcing me to do a forklift upgrade of my kernels or hand roll my own patches.
This is what RedHat gets paid for.
It's been working fine for me since FC2 came out: I don't have to hand-roll my own kernels anymore, and packages for things like video translation libraries are available in RPM form from the "dries" repositories, in yum-compatible mirror shites.
This is not a good assumption. Go over to bugzilla.redhat.com and see if it's documented and marked as "fixed" there. Sometimes a "well-known bug" doesn't get submitted, sometimes fixing it would take a major re-write of something the vendor isn't ready to take on (such as parted or the kernel itself).
Gcc is not a necessary component of anything but development tools: as a production tool, it's not directly relevant to whether you can do the systems upgrade.
glibc and kernels and the RPM package management themselves are another story. It's been possible in the past to upgrade one component without upgrading the other and to really screw up the working base of your system so you had to clean things up by hand or simply do a re-install.
Yum and possibly apt, actually help quite a lot with this by giving you good lists of related dependencies to update and by looking both in the update directory and the base directory for components to satisfy dependencies.
And don't forget the unspeakable act committed upon the corpse of the alian leader.
It's a good thing our hero had something to read while doing that....
Slashdot Mirror
Agreed. I've found the most stable way to use an old Sun is to install Linux on it, rather than deal with the pain of accomodating a difficult to support and always out-of-date on core tools OS like Solaris.
If Solaris 10 is a departuture from their more closed models, that would be great.
No, they made it easier when they let someone steal all their source code last year, then used it as an excuse to delay their game release for a year while providing no significant changes in the security models of their software.
Silly people.
No, it doesn't help much. Domain keys, like Microsoft's SenderID, rely on the sender to purchase or generate a key, and on the recipient's client or their SMTP server to decrypt the public key. This is a significant computational load on the recipient: if it wasn't, there'd be no point because the keys would be easy to forge.
Expect this system to seriously bog down typical mail servers which already run at 20% or better of their available CPU capacity, especially if it gains any prevalence or is used for mailing lists for which email arrives for multiple users in big bundles.
Solaris doesn't ship with a compiler, hasn't for at least seven years. If you paid for their compiler and don't like it (sucker), use gcc.
That's right, you have to pay a significant chunk of cash to get their compiler. I didn't bother mentioning that part. But to take real speed a nd performance advantage of the Sun architectures, you need the Sun compilers.
Yeah, including display postscript was a real bastard move.
No, it was merely a miserable failure. The use of commercial proprietary toolset as the underlying architecture was doomed to failure, in a way that X11 and the other X architectures have not been.
They include open-source tools like that with Solaris 9. The tools have always been available elsewhere.
Yes, because people like me built them up from scratch and published our patches and packages. What in the heck do you think I wasted so much time doing dealing with Solaris but getting such tools ported over so they could be actually used in a large and mixed environment?
That is not Sun's fault. For that matter, try porting most of the stuff you find bundled with a Linux distro to any other platform... hell, just try porting all the tools you need to build it...
I have. I've been doing it for years. The GNU stuff is pretty easy to bring over, once you have a few basics installed. It gets far more difficult to do when you have to deal with Sun's traditionally closed source stuff, like NIS, their libc, and their graphical display tools.
Sorry, I came to Solaris from the SunOS world. I've administered a bunch of flavors of SunOS, Solaris, Linux, and other OS's. The "time to set up your environment" has traditionally been time wasted from my life, especially trying to repackage things. I found the best way to set up a stable server for basic mail or file server utilities with Sun hardware was to install Linux on it, at least a few years ago.
And you've apparently never dealt with the vagaries of transporting locally written X-Windows or video image handling tools from Sun to elsewhere. At least a few years ago, the Sun include files could be called multiple times and do different things because they didn't use an "I've already been called!" flag, and ifdef values would be changed by the time it got called the second time. That was extremely painful to deal with.
Go hit the universities, office, and R&D environments. Solaris is still used as server class machines, but the last place I worked deliberately suspended all work and development with Solaris years ago because the workstations were overpriced and non-competitive with what a PC running Linux could do: they just weren't worth it in the desktop machine market.
Administering Solaris has been, traditionally, as much work as administering 3 different Linux releases at the same time. The subtle distinctions between their various compilers, the oddness they did to X, and their refusal to replace their various shells and command line utilities like "compress" with the vastly superior open source tools like "gzip" meant that to do any real work, you had to spend a huge amount of time porting over your tools both ways. And porting Solaris code to the non-Solaris world is often quite difficult.
I hope this change encourages Sun to go the open source route on core utilities, and spend their development time on the kernel and the compiler. While their hardware has been interesting, I really feel that it's not going to be a big driver for them in the face of AMD's now stable and quite inexpensive 64-bit architectures, which is the market where Sun should have focused their hardware development for the last 5 years.
Yes, this works fine. Also, Fedora is quite nice about using the "yum" command to fetch the particular package you want and all its dependencies, or removing them, after your OS is installed.
The stripped down version is CD 1, which allows you to do a "minimal" install.
Fedora is a testbed for RedHat Enterprise Linux. As such, it tends to have a lot of cutting edge tools, which get tested and refined into things that are worth putting into RHEL. That's how RedHat justifies doing this completely "free" release but providing to consumer grade support.
The result is not bad. Patches are fast, feature additions are fast and furious, and they do seem to be listening to complaints in their bugzilla quite well and fixing them ASAP.
The bulk mail discounts are *huge*. The Post Office is kept afloat by junk mail: it's one of the federal offices that actually makes a profit, but it does so because bulk mail is very easy to process with all the bar code scanners and older bulk mail handling techniques. If it weren't easy and cheap, far more of your mail at home would actually be worth reading rather than the 90% that most of us simply throw away.
Even if sentenced to 9 years (which is extraordinarily unlikely), he's unlikely to spend more than a year in jail. It's not a violent set of crimes, the US jails are overloaded with poor convicts on various drug charges, and he'd be extremely likely to be on parole. He's got the smarts and social skills to run a significantly sized business, the parole board is unlikely to hold him in jail a moment more than necessary.
It's called a "pink contract", a business contract with the clauses that normally forbid business like spamming carefully left out. They're quite common for struggling ISP's, which normally make sure the bandwidth is paid for up front. agis.net did this for quite some time with Cyberpromo, until the crackers took their routers down and kept them down until Cyberpromo went offline. But it took almost 2 years to get people worked up enough that the crackers would do this.
There is no way in hell this guy is going to jail for nine years. Despite his blatant fraud, the Direct Marketing Association is lending him legal support lest precedents get set that will encumber their commercial spam and junk mail. The ISP that sold him the multiple T1's or T3's is doubtless going to help out in court as well, to avoid liability for their laxity in not acting against all the complaints.
Even Sanford Wallace, the king of spam at cyberpromo.com for some years, is already back in business after numerous court losses, which he normally handled by settling out of court before he could be convicted.
Expect a "stiff fine" at worst for this spammer, and for him to be back in business within six months.
That's really strange, because I never saw an arrest, prosecution, or even a formal accusation out of Valve software.
What I saw was a a lot of lies designed to keep investors off their back: "They used an Internet Explorer bug", which is possible but unlikely. Social engineering of one of their employees or guessing a trivial password are far more likely ways into a remotely secure network. "They only got a little bit of the source code", which was a blatant lie because pirated copies of Half-Life 2 turned up in Russia with newly dubbed voices. "We'll be slightly delayed", which was another lie because it took more than another year to get the game out.
Stealing your source code is no excuse for having such a late release date, unless the game was absolutely not ready for release and you used the theft as an excuse to do the sort of complete design and security work you should have done in the first place. Given Valve's and ATI's cooking of the video results in the ATI/Nvidia video card comparisons, I don't think you can trust Valve the company's claims about anything.
The games have been good: games are not designed by corporate boards. But public press announcements, release schedules, and cooked demos are.
From the dotcom era, it's easily 3 out of 4 entirely underwater. Owners of real stock, however, seem to have done better. They still have some value left, and even if the company was going completely under could recoup some small value by selling it.
VP's and their ilk often have extensive insider iniformation that allows them to sell off or buy hunks of stock before the "blackout period" immediately surrounding big business announcements. Sad, but true. It's how so many of them also know to retire or "move on in their career" and cash out their options, just before the big trouble hits the papers.
Sad, but true. I've actually seen a VP cover his ears and go "la-la-la-la, I can't hear you talk about this because I'm selling stock, la-la-la-la!" We had to actually go find another VP to discuss the very bad matter about to happen with, to get their approval to can a business partner.
Now, folks, notice the shell game this fellow just did. He succeeded in conflating ESPP and "employee pay over the minimum to get you is wasted" with stock options. These are each very, very distinct issues. The conflation and shell game are part and parcel of the stock sales game. The .sig is also nice hook to try and rope in some extra business from slashdotters who are convinced of the
Stock options at the typical employee level are betting your man-hours, your hard-work and time, against the increasing stock value of the company. They're also where companies hide money for executives: there's a fascinating set of income tax and reporting requirement laws that take effect when a CEO or other corporate officer makes over $1 million/year, that are frequently evaded by paying exceptional amounts of stock options that need not be reported to the stock holders.
It's a nasty world out there. Watch your backs.
No. Stock options are not stock. The company does not pay dividends, you cannot sell them at whim, and they're worth exactly nothing if the company value does not go up. It actually makes it advantageous for the company to keep the stock value low, bump it high with some faked up announcement so the the VP's can sell their options at a fraudulent value quickly before the employees can blink, then step out or even quit before the fraud comes home. Why do you think it's called "pump and dump"?
Bingo. STock options were a way to pay people in the future of the company: they were used to give wildly underpaid employees, and investors, something on paper. Unfortunately, they're only valuable when the company's stock value goes up.
Now look very carefully. The only people who can sell them when the company makes its IPO are VP's. The employees are prevented by lockout periods from selling them when they are most valuable, right after the IPO or when they have some value left, right before the company tanks. VP's, however, get to sell them with the insider knowledge that they're not supposed to use, and they get nice golden parachutes when the company tanks. In a few cases, the employees can get more value than the many man-hours they invested and the pay they didn't get to take the stock options instead. And in a few cases, people win big lottery options that are worth more than all the lottery tickets they personally bought.
But they're not a good investment idea for most of us who do the real work. In most cases, they're a place to hide money to pay off the highest level staff, in a way that the company doesn't have to show on their books and will never have to redeem except for those high level staff who can sell them when they have value.
Use yum. Make a copy of your yum.conf called yum.conf.update, and replace the $releasever everywhere with the number "3". Then run "yum clean; yum -c yum.conf.update check-update" to pre-load the header files files, and "yum -c yum.conf.update yum; yum -c yum.conf.update update" to actuall do the updates. The new version of yum has some nice pre-downloading features, which is why I recommend updating it first.
Me too. I want them to backport clear kernel fixes and driver additions to the older kernel, rather than publishing a fresh-off-the-presses and not yet stable kernel and forcing me to do a forklift upgrade of my kernels or hand roll my own patches. This is what RedHat gets paid for.
It's been working fine for me since FC2 came out: I don't have to hand-roll my own kernels anymore, and packages for things like video translation libraries are available in RPM form from the "dries" repositories, in yum-compatible mirror shites.
This is not a good assumption. Go over to bugzilla.redhat.com and see if it's documented and marked as "fixed" there. Sometimes a "well-known bug" doesn't get submitted, sometimes fixing it would take a major re-write of something the vendor isn't ready to take on (such as parted or the kernel itself).
Gcc is not a necessary component of anything but development tools: as a production tool, it's not directly relevant to whether you can do the systems upgrade.
glibc and kernels and the RPM package management themselves are another story. It's been possible in the past to upgrade one component without upgrading the other and to really screw up the working base of your system so you had to clean things up by hand or simply do a re-install.
Yum and possibly apt, actually help quite a lot with this by giving you good lists of related dependencies to update and by looking both in the update directory and the base directory for components to satisfy dependencies.
And don't forget the unspeakable act committed upon the corpse of the alian leader. It's a good thing our hero had something to read while doing that....