folks dont change schedulers as part of minor patch releases
As an aside, you can actually run different schedulers concurrently in Solaris... each process or process group can be assinged a specific scheduler other than the default one (which is Time Share, or the "TS" scheduler).
For example, you can run your Oracle db processes with the FX (fixed priority) scheduler, and/or another set of processes with the RT (real time) scheduler. See the priocntl command man page on how to manipulate this and details on which schedulers are available.
The RAID controllers on the X4x00 servers (excluding the X4500) are built in to the SAS controller chip itself, which is a LSI Logic 1068.
I have a negative view regarding the utility of doing RAID 0 or 1 (or 10 for that matter) in hardware. There's really no performance benefit since those controller chips sit right on a PCIe buss, and RAID 0 and 1 don't require anything of the CPU in terms of parity calculation nor do they have the downside of partial stripe writes at higher RAID levels.
You're also removing direct visibility of the disks from the OS, and I tend to think (through experience) that when it comes down to error detection and maintenance, you're better off doing all your mirroring/striping in one place, in software (eg; using SVM or ZFS).
1) The only Sun x86 servers which are SATA-only are the low end X2100 and X2200. The rest (X4100 and up) are 2.5", 10k RPM SAS drives. There is one Sun x86 server which has SCSI internally, and that is the left-over V40z. I think Sun still keeps it in the product line up because it has 4 sockets.... but it's a product that will probably be replaced soon.
2) The iLOM included with the X2100/X2200 M2 and the X4x00 servers is actually really, really nice, and just as capable than the ALOM in the SPARCs. The bonus with iLOM is that it has IPMI and a web interface along with a SSH cli, where the ALOM is telnet (old ALOM) or SSH (new ALOM found on the UltraSPARC T1-based servers)
3) Simple solution to the side effect of using GRUB on Solaris x86 - have a cron job that runs 'bootadm update-archive' a few times a day. The only time you could run into the problem you describe is if you install kernel patches and don't reboot (or run bootadm manually). You do reboot after installing kernel patches, right?
It took a big leap of faith to move my shop from Solaris/SPARC and Linux/x86 to Solaris/x86, and really I'm pretty happy with how it's gone over the 2 years that this process has been happening.
I imagine that this phone would support CalDAV, as that is being touted as a new iCal feature in the forthcoming Leopard release of OSX. The iCalendar Server you mention is based around CalDAV. Theoretically, since Apple is making CalDAV a central theme with their iCal client and in their server, I can only assume that this smartpdaphone would be a CalDAV client as well, and thus be able to interface with other calendaring servers which support CalDAV.
Two weeks ago we implemented 3-factor greylisting here at the university I work at. We went from delivering 700,000 emails per day to 200,000 after turning it on, which works out to about 10 messages per day, per email box on average... certainly a more realistic number. The response from the users has been great (some even thought that our email system was broken at first because they stopped getting so much noise in their inbox/spam folder, the change was that dramatic).
Naturally, the work-around for spammers is to resend their spams, but they would have to do it from the same IP and with the same envelope from and to address. This means that their army of zombie'd PCs would have to work twice as hard if everyone greylisting was common practice, and likely a require a non-trivial change to the software on these zombies. We'll have to see how it pans out, but after watching my greylist logs and inspecting the spams which do get through, it seems that perhaps a few spammers have already caught on to this, but not all. Most of the spams which do get through our greylisting are subsequently caught by Spamassassin and RBLs, and come from open-relays (those still exist!)
While I'm not thoroughly educated on this particular subject, I would say that it's a pretty good chance that the flight computers on the shuttles are based on technology that's at least 15 years old (all shuttles underwent a "glass cockpit" update in the mid-late 90s). You don't see NASA cutting a purchase order to cdwg.com when the newest AMD or Intel offering is announced and stuffing that into the shuttles. This stuff is designed, planned, coded for and integrated over a number of years and is very static. No changes. If there has to be changes, they're done under a quality control methods so strict that, yes, Duke Nukem 3D might see the light of day first.
And that's just the hardware part.
On the software side, I'd say you're probably looking at stuff written in any assortment of "classic" languages such as ADA, COBOL, or worse. Due to the nature of the metric f*k ton of sensors, mechanical servos, data inputs, and other such esoteric (and dated) hardware on the shuttles, the software must control, query, parse and monitor, the software is pretty darn married to the platform it runs on.
So, before blurting "D0odz, just instahl leenux n yr shuttlz (deeban stble rox wif glox!)" Give it some deeper thought. There's likely a darn good reason why things are they way they are (bugs not withstanding) when it comes to large flying contraptions that are designed to safely get 7 people 300 miles up, keep them there for a week (or two) and get them home. Sometimes simple things (to you and I) such as a year roll-over are outside the scope when it comes to designing systems to do what the shuttle does.
You might want to check out the DTrace Toolkit and take a look at the DTrace scripts it includes. Many of the tools you see there are very admin-oriented, and those are mostly simple examples of what can be done with DTrace
Remember, it offers observability to most, if not all, of the system in a variety of ways which makes DTrace suitable for both admins and develoopers.
System performance tuning using DTrace and a typical Solaris IT wonk (a population that tends to correlate highly with the fanboys pushing DTrace the hardest) is a recipe for disaster.
Care to expound on how that could be? It sounds like the most you've done with dtrace is read some online docs about it (or worse, the wikipedia entry), said "hmph" to yourself, and quickly moved on. I'm curious as to why you feel that you must spare no effort in disparaging "Solaris IT wonks" for whatever reason. Let us talk about "Linux IT wonks" and what gets them all hot and bothered to the point of fanboyism, shall we? There certainly wouldn't be a shortage of subject matter for that discussion.
The door swings both ways, bud. Good tools are good tools and there's no harm in letting the people who like the tool also be proud of the tool. To frown on that stinks of sour grapes.
I think MIPS was the popular arch to learn asm on. Here at UMBC, MIPS is still what the assembly programming courses revolve around. In the mid 90s, SGI/IRIX was popular in (american, at least) universities. This course is pretty much one of the only reasons why we keep a few O200s around (including a 24-CPU Challenge XL... well, okay, it's now 16 CPUs, because we seem to be seeing one CPU board die each year). It's funny because back in the 90s, the Challenge XL was billed to faculty as a high-speed research computing server, which it was - at the time. Some of the old timers believe that's still is true today, probably because they just don't know better. 16x 200Mhz CPUs ain't all that, no matter what arch you're on.
Hopfully we can convince the CS dept to move their course off of MIPS so we can push these aging servers off the end of the loading dock. SPARC or x86/64 would be the alternatives here.
This box is 100% designed to be used in mutual full advantage with ZFS. Thumper is what you would call a modern RAID array, as ZFS in this case blurs the destinction between hardware and software RAID. The CPU and memory horsepower is there for RAID-Z.
From this box, one can serve out file systems with NFS and/or SMB/CIFS (aka a traditional NAS), and in future releases of Solaris 10, also serve out LUNs over iSCSI and FCP while having all that data backed by the performance, reliability, and features of ZFS. The only thing it's missing is a consolidated, centralized CLI for manipulating storage, a la NetApp and ONTAP... but all the requisite pieces are there to turn Solaris, and especially Solaris-on-Thumper, into a NetApp killer at less cost.
As much as people tend to bash it, but speaking in relative terms, iTMS still has the most consumer-friendly terms compared to other major players out there. Subscription models work only for magazines and pron accounts... an no one takes my magazines away if I end my subscription to it.
You're forgetting that reactive armor is a one-shot deal. Once the armor panel is used to counter the impact of a projectile, it's done. The vehicle is then vulnerable in that area until the spent reactive armor is replaced.
This new system makes it so that there is no impact. It's inherently reusable, so long the magazine of whatever launches the counter-projectile is large enough in capacity and/or can be safely reloaded by the vehicle crew. The only achilies heel that I can see is the damage or destruction of a radar panel... but I imagine those photos of test vehicle in TFA aren't of what the config will look like in production.
This is money well-spent, not reinventing the wheel.
What else would you expect from the market leader (leader in sales, leader in songs, and most importantly, the leader in the tech that goes into these things)? You gotta move fast when you're the target of the rest of the industry.... reasons like this is why there's no real "iPod killer" yet.
I like it. I hope Apple keeps it up. When I upgrade from my 3G iPod, I'll pick a new(ish) one that has the features I know I need and be happy with it for another 3 years.
Besides, how many times have we seen a company come out with a thrilling and great product but then just rests on their laurels while everyone else catches up and then surpasses them? *cough*Audiotron*cough*
In mid 2005 we here at UMBC moved our AFS servers from a bunch of individual Dell/Linux and Sun/Solaris servers with DAS JBODs to Sun V20zs on a fabric with the Xserve RAIDs LUN'd out for each server. We love this set up and the Xserve RAIDs perform amazingly well for what they do (email, home directories for 15k active users). They're cheap, straight-forward to manage, and so far seem quite reliable.
You only need to think a little more to find the answer to your question - and that is before OpenSolaris, Sun was the sole maintainer so any arch port decisions were done from a purely business-related standpoint. Sun as a company had no interest in seeing Solaris running on DEC Alpha hardware or a HP PA-RISC machine.
Now that there is OpenSolaris, there's already a project to port it to PPC (bit of history: there was a version of Solaris 2.4 (circa 1994) that Sun made and it ran on PPC 604 CPUs, rumor has that it was one-off for a "special customer")
So don't just knee-jerk and say Well Linuxth runths on 35 plathforms so Solaris must be hardth to portht... you need to think of the whole picture.
If such fanciful upsampling algorithms were able to be done, they would have existed already. But the fact is, is that the sonic "sugar" that this new Creative chip adds makes anyone who is reasonably knowledgable (and I mean in more than "I know what kilohertz means" way) just smack their forehead and groan.
This sounds like anti-aliased audio on a huge scale, and I rekon the audio this produces comes at a cost to the original audio's dynamics and in a big way. To put it simply, you can polish a turd and expect it to look better.
back in the old days, we had to telnet in to the slashdot server and read the MOTD to see the articles! Comment were through talk(1). I knew things were going downhill when on that fateful day Taco "upgraded"./ to gopher.
Slashdot Mirror
folks dont change schedulers as part of minor patch releases
As an aside, you can actually run different schedulers concurrently in Solaris... each process or process group can be assinged a specific scheduler other than the default one (which is Time Share, or the "TS" scheduler).
For example, you can run your Oracle db processes with the FX (fixed priority) scheduler, and/or another set of processes with the RT (real time) scheduler. See the priocntl command man page on how to manipulate this and details on which schedulers are available.
"It's time to un-PMP ze audio"
The RAID controllers on the X4x00 servers (excluding the X4500) are built in to the SAS controller chip itself, which is a LSI Logic 1068.
I have a negative view regarding the utility of doing RAID 0 or 1 (or 10 for that matter) in hardware. There's really no performance benefit since those controller chips sit right on a PCIe buss, and RAID 0 and 1 don't require anything of the CPU in terms of parity calculation nor do they have the downside of partial stripe writes at higher RAID levels.
You're also removing direct visibility of the disks from the OS, and I tend to think (through experience) that when it comes down to error detection and maintenance, you're better off doing all your mirroring/striping in one place, in software (eg; using SVM or ZFS).
Not to nitpick, but to weigh in:
1) The only Sun x86 servers which are SATA-only are the low end X2100 and X2200. The rest (X4100 and up) are 2.5", 10k RPM SAS drives. There is one Sun x86 server which has SCSI internally, and that is the left-over V40z. I think Sun still keeps it in the product line up because it has 4 sockets.... but it's a product that will probably be replaced soon.
2) The iLOM included with the X2100/X2200 M2 and the X4x00 servers is actually really, really nice, and just as capable than the ALOM in the SPARCs. The bonus with iLOM is that it has IPMI and a web interface along with a SSH cli, where the ALOM is telnet (old ALOM) or SSH (new ALOM found on the UltraSPARC T1-based servers)
3) Simple solution to the side effect of using GRUB on Solaris x86 - have a cron job that runs 'bootadm update-archive' a few times a day. The only time you could run into the problem you describe is if you install kernel patches and don't reboot (or run bootadm manually). You do reboot after installing kernel patches, right?
It took a big leap of faith to move my shop from Solaris/SPARC and Linux/x86 to Solaris/x86, and really I'm pretty happy with how it's gone over the 2 years that this process has been happening.
Perhaps his roof isn't well-oriented towards the south, and the other building's roof is.
You don't dump half a million into a project only to have the solar cells facing away from the sun.
I imagine that this phone would support CalDAV, as that is being touted as a new iCal feature in the forthcoming Leopard release of OSX. The iCalendar Server you mention is based around CalDAV. Theoretically, since Apple is making CalDAV a central theme with their iCal client and in their server, I can only assume that this smartpdaphone would be a CalDAV client as well, and thus be able to interface with other calendaring servers which support CalDAV.
Two weeks ago we implemented 3-factor greylisting here at the university I work at. We went from delivering 700,000 emails per day to 200,000 after turning it on, which works out to about 10 messages per day, per email box on average... certainly a more realistic number. The response from the users has been great (some even thought that our email system was broken at first because they stopped getting so much noise in their inbox/spam folder, the change was that dramatic).
Naturally, the work-around for spammers is to resend their spams, but they would have to do it from the same IP and with the same envelope from and to address. This means that their army of zombie'd PCs would have to work twice as hard if everyone greylisting was common practice, and likely a require a non-trivial change to the software on these zombies. We'll have to see how it pans out, but after watching my greylist logs and inspecting the spams which do get through, it seems that perhaps a few spammers have already caught on to this, but not all. Most of the spams which do get through our greylisting are subsequently caught by Spamassassin and RBLs, and come from open-relays (those still exist!)
You're indeed missing something here.
While I'm not thoroughly educated on this particular subject, I would say that it's a pretty good chance that the flight computers on the shuttles are based on technology that's at least 15 years old (all shuttles underwent a "glass cockpit" update in the mid-late 90s). You don't see NASA cutting a purchase order to cdwg.com when the newest AMD or Intel offering is announced and stuffing that into the shuttles. This stuff is designed, planned, coded for and integrated over a number of years and is very static. No changes. If there has to be changes, they're done under a quality control methods so strict that, yes, Duke Nukem 3D might see the light of day first.
And that's just the hardware part.
On the software side, I'd say you're probably looking at stuff written in any assortment of "classic" languages such as ADA, COBOL, or worse. Due to the nature of the metric f*k ton of sensors, mechanical servos, data inputs, and other such esoteric (and dated) hardware on the shuttles, the software must control, query, parse and monitor, the software is pretty darn married to the platform it runs on.
So, before blurting "D0odz, just instahl leenux n yr shuttlz (deeban stble rox wif glox!)" Give it some deeper thought. There's likely a darn good reason why things are they way they are (bugs not withstanding) when it comes to large flying contraptions that are designed to safely get 7 people 300 miles up, keep them there for a week (or two) and get them home. Sometimes simple things (to you and I) such as a year roll-over are outside the scope when it comes to designing systems to do what the shuttle does.
You might want to check out the DTrace Toolkit and take a look at the DTrace scripts it includes. Many of the tools you see there are very admin-oriented, and those are mostly simple examples of what can be done with DTrace
Remember, it offers observability to most, if not all, of the system in a variety of ways which makes DTrace suitable for both admins and develoopers.
System performance tuning using DTrace and a typical Solaris IT wonk (a population that tends to correlate highly with the fanboys pushing DTrace the hardest) is a recipe for disaster.
Care to expound on how that could be? It sounds like the most you've done with dtrace is read some online docs about it (or worse, the wikipedia entry), said "hmph" to yourself, and quickly moved on. I'm curious as to why you feel that you must spare no effort in disparaging "Solaris IT wonks" for whatever reason. Let us talk about "Linux IT wonks" and what gets them all hot and bothered to the point of fanboyism, shall we? There certainly wouldn't be a shortage of subject matter for that discussion.
The door swings both ways, bud. Good tools are good tools and there's no harm in letting the people who like the tool also be proud of the tool. To frown on that stinks of sour grapes.
Ah, good news then. I guess things are progessing over there in the ITE building :)
I think MIPS was the popular arch to learn asm on. Here at UMBC, MIPS is still what the assembly programming courses revolve around. In the mid 90s, SGI/IRIX was popular in (american, at least) universities. This course is pretty much one of the only reasons why we keep a few O200s around (including a 24-CPU Challenge XL... well, okay, it's now 16 CPUs, because we seem to be seeing one CPU board die each year). It's funny because back in the 90s, the Challenge XL was billed to faculty as a high-speed research computing server, which it was - at the time. Some of the old timers believe that's still is true today, probably because they just don't know better. 16x 200Mhz CPUs ain't all that, no matter what arch you're on.
Hopfully we can convince the CS dept to move their course off of MIPS so we can push these aging servers off the end of the loading dock. SPARC or x86/64 would be the alternatives here.
Sun is indeed currently working on a iSCSI Target (and possibly FCP target as well) server.
http://www.opensolaris.org/os/project/iscsitgt/
This box is 100% designed to be used in mutual full advantage with ZFS. Thumper is what you would call a modern RAID array, as ZFS in this case blurs the destinction between hardware and software RAID. The CPU and memory horsepower is there for RAID-Z.
From this box, one can serve out file systems with NFS and/or SMB/CIFS (aka a traditional NAS), and in future releases of Solaris 10, also serve out LUNs over iSCSI and FCP while having all that data backed by the performance, reliability, and features of ZFS. The only thing it's missing is a consolidated, centralized CLI for manipulating storage, a la NetApp and ONTAP... but all the requisite pieces are there to turn Solaris, and especially Solaris-on-Thumper, into a NetApp killer at less cost.
It's called The Paul E Garber facility, and it does have occasional openhouses.
http://www.nasm.si.edu/garber/
Not to mention that it's pretty hard to build a fully static binary because Solaris 10 does not include static analogs of libc and friends.
I'll take purchase-to-own for $0.99, Alex.
As much as people tend to bash it, but speaking in relative terms, iTMS still has the most consumer-friendly terms compared to other major players out there. Subscription models work only for magazines and pron accounts... an no one takes my magazines away if I end my subscription to it.
That depending on the movie that follows it, that sound is the best part of the sitting.
You're forgetting that reactive armor is a one-shot deal. Once the armor panel is used to counter the impact of a projectile, it's done. The vehicle is then vulnerable in that area until the spent reactive armor is replaced.
This new system makes it so that there is no impact. It's inherently reusable, so long the magazine of whatever launches the counter-projectile is large enough in capacity and/or can be safely reloaded by the vehicle crew. The only achilies heel that I can see is the damage or destruction of a radar panel... but I imagine those photos of test vehicle in TFA aren't of what the config will look like in production.
This is money well-spent, not reinventing the wheel.
What else would you expect from the market leader (leader in sales, leader in songs, and most importantly, the leader in the tech that goes into these things)? You gotta move fast when you're the target of the rest of the industry.... reasons like this is why there's no real "iPod killer" yet.
I like it. I hope Apple keeps it up. When I upgrade from my 3G iPod, I'll pick a new(ish) one that has the features I know I need and be happy with it for another 3 years.
Besides, how many times have we seen a company come out with a thrilling and great product but then just rests on their laurels while everyone else catches up and then surpasses them? *cough*Audiotron*cough*
In mid 2005 we here at UMBC moved our AFS servers from a bunch of individual Dell/Linux and Sun/Solaris servers with DAS JBODs to Sun V20zs on a fabric with the Xserve RAIDs LUN'd out for each server. We love this set up and the Xserve RAIDs perform amazingly well for what they do (email, home directories for 15k active users). They're cheap, straight-forward to manage, and so far seem quite reliable.
Details on our setup here.
Wow. Just wow.
I look at Solaris (err, OpenSolaris) and how it can now push a 10Gb/s interface at line speed (or close to it) and MS has struggled up until recently to get satisfactory speeds above 10Mbit/s ?
Yet another "how do users/admins accept this as OK" thought going through my head re: Windows internals.
You only need to think a little more to find the answer to your question - and that is before OpenSolaris, Sun was the sole maintainer so any arch port decisions were done from a purely business-related standpoint. Sun as a company had no interest in seeing Solaris running on DEC Alpha hardware or a HP PA-RISC machine.
... you need to think of the whole picture.
Now that there is OpenSolaris, there's already a project to port it to PPC (bit of history: there was a version of Solaris 2.4 (circa 1994) that Sun made and it ran on PPC 604 CPUs, rumor has that it was one-off for a "special customer")
So don't just knee-jerk and say Well Linuxth runths on 35 plathforms so Solaris must be hardth to portht
If such fanciful upsampling algorithms were able to be done, they would have existed already. But the fact is, is that the sonic "sugar" that this new Creative chip adds makes anyone who is reasonably knowledgable (and I mean in more than "I know what kilohertz means" way) just smack their forehead and groan.
This sounds like anti-aliased audio on a huge scale, and I rekon the audio this produces comes at a cost to the original audio's dynamics and in a big way. To put it simply, you can polish a turd and expect it to look better.
back in the old days, we had to telnet in to the slashdot server and read the MOTD to see the articles! Comment were through talk(1). I knew things were going downhill when on that fateful day Taco "upgraded" ./ to gopher.