To my knowledge, it isn't a choice. I *had* to learn cursive 20 years ago in elementary school, my younger sisters *had* to learn it 4 years ago in elementary school.
We aren't given a choice, but as soon as we get out of school (or reach a grade where the teachers don't care), we quickly realize that print is so much easier than cursive.
Proper handwriting is all well and good, but if it takes noticeably longer to read my notes, screw it. Considering how little free time people have anymore, it doesn't make sense to waste one more second than you have to on reading. Print is more legible, therefore it will be the favored script.
It's not about whether or not learning to write matters, it is about one particular script. If print script is the only one taught, we are still teaching writing. We're just making the natural transition to a simpler script.
I see it as similar to, say, Russia deciding to only teach the romanized script instead of the old Cyrillic. They are still being taught to write, albeit in a different script.
I don't really see any computer-related cause. Cursive has declined for decades. We just don't care how pretty our words look on paper anymore. That was the whole appeal to cursive: adding unnecessary pen strokes to make the letters look nice.
Except there's a problem. When you don't write cursive regularly, your signed name eventually devolves into a wiggly line, which is completely useless from a forensic standpoint.
Most people write faster with print. Cursive and print are just form vs function. Cursive is pretty, and was all the rage back when people cared about penmanship. Print is utility, quick and dirty.
Well, a lot of people use a bastardized system like me: print letters with the bottoms joind (like cursive).
Printing the letters can actually be faster. Consider the letter 't'. In cursive (the way I was taught, at least), you start at the bottom, go up, then back down, then pick up the pen and cross it. In print, you start at the top, go down, pick up the pen and cross it. An entire stroke is cut out of the process.
Cursive has always been slower for me because of all the extraneous strokes it adds (think about the capital G and S, for example).
I've heard that it is fast, but I have always found cursive to be slow. Over time, I've adopted a sort of bastardized script. Normal printed letters joined at the bottom (a la cursive). Faster than plain print, since I don't lift the pen very often, and far more legible than cursive.
I like your concept of simplifying the writing style. Calligraphy can be beautiful, but I hate seeing a thousand needless loops in someone's day-to-day writing.
At 5.5 mil LOC, you'd be lucky if you could even *find* the source of one bug a day.
There is a balancing act involved. I remember an old chestnut that said something to the effect of "A product is good enough to release when it works for 85% of the people trying to use it". Go above 85%, and you start getting diminishing returns on cost. Could they fix every single little glitch? Sure. From a business perspective, is it worth the price? No way.
The whole point of the Mythical Man Month is not that more coders never means more productivity, it is that there is a balance point at which going beyond it does not increase productivity. 3 is better than 1, but 3000 is not always better than 1000. At this point, 32 is probably enough. Maintaining a codebase and adding new features requires a lot fewer devs than the initial development of the product. Most of the leg work (back-end, tool suite, etc) has already been completed.
Well yeah, in this case it isn't bad. I was referring more to the practice of just turning AU on and forgetting about it. If you're controlling when everything is pushed out from WSUS, I wouldn't really consider it "automatic" anymore.
Yup, when it comes to servers, the admin is more important than the OS. If the admin knows what he's working with, he can keep even the worst OS more or less secure.
We had a similar issue at work. Our servers were all working off a group policy that allowed AU. It was set up that way long before I started there. Sure enough, AU took down the mail server one day while forcing a reboot after a patch. Lesson learned.
The biggest threat to security is an admin who isn't intimately familiar with their systems. We've all been there at least once =)
I blame the admins there. If they aren't paying attention to vulnerabilities in their server packages, they're shitty admins. Windows servers are the same way. No admin worth the title runs AU on a production server, and they take just as long to patch their servers.
Yup. I just restored a laptop last month for one of our employees whose home ISP (Brighthouse) disconnected him until he could show them that the machine had been repaired.
I thought this was common practice among major ISPs. We've seen the same here at work, when we were contacted early this year when our ISP noticed some spam coming from our mail server.
Machine had 2 GB of RAM, so memory shouldn't be the issue. The CD drive had to be recognized since I was able to boot the Debian installer. The problem I ran into was an error during the install phase that couldn't be worked around.
Yeah, and I can understand the sentiment. It usually is one of the biggest problems. Windows users treating Linux like Windows, Python coders treating it like C++, etc. A lot of "newbie" issues with most things can probably be traced back to them just not realizing that they have to treat the new *whatever* as a different entity from what they are used to.
I spent a couple weeks on this issue. Looked at the HCL, the BigAdmin stuff, pored through Google and all the OSOL docs and ml archives I could find. I just happened to be unlucky and had a hardware config that I couldn't tweak into working. Just one of the perils of early adoption =)
Yup, I always have a FreeBSD guest installed in VirtualBox. I've always like the BSD distros, mainly for the reason you mentioned (getting the best of both worlds...old-school Unix and Linux).
Yup, it has definitely improved. Another year or two with the right focus and it could be really useful. I'll continue to keep an updated install in VirtualBox for testing (I agree about hardware issues). Of course, VirtualBox has its own issues with OSOL (building the guest tools really mucked things up, but I blame VB for that, not OSOL).
My first experience outside MS was actually in Solaris, and I migrated to Linux later. I'm familiar enough with Solaris from my early days that I understand it has to be treated differently.
And yeah, I'd been through the HCL and knew that this particular model wasn't supported. But I also know that HCL's aren't always comprehensive and you can sometimes get away with installs on other hardware with a little tweaking.
I'm not saying OSOL is bad, I really do love some of the features, I just don't find it to be better than Linux (in a general sense, I'll agree that some aspects *are* better) in its current state. In the future, who knows. With the right work, it could be a great alternative.
I haven't tried vanilla Solaris, and we didn't currently have any Solaris media (we're mainly an MS shop with a handful of Linux servers/VMs and Xserves...though I'd prefer the reverse *grin*)
These machines aren't intended for production use anytime soon. We're using them now just to play around, get familiar with the hardware, poke around in the apps. Mainly just prep work in the event that we need to support Sun machines for a client sometime in the future.
I haven't tried it on a diskless system, but I didn't really have any issues installing Debian on the Sunfire servers (all were headless).
Started the install through the serial port, configured SSH and did the rest through an SSH conn (serial is just too painful on the eyes *grin*)
I can't speak for all distros, but I've found serial setups to be fine in both Debian and Gentoo (my two primary distros over the past 8 years).
The OSOL install isn't really *bad* up to the point where it failed (though I really have complaints with the network install process), I just ran into the issue of trying to install it on SPARC hardware that wasn't yet supported in OSOL. I come from being an early Gentoo user doing Stage 1 builds. Consoles and serial port installs don't bother me a bit, and I'm sure the install process will get better as time goes on and support is improved =)
Aye, deb packages aren't bad, and I've had good experiences with Gentoo's portage setup (though that seems to have gone downhill the last couple years). RPM is my least favorite of the major package formats, though I may just be biased from my memories of RH and dependency hell years ago *grin*
Well, I couldn't even get OSOL installed on the SPARC machines, so my experience on that side comes from my experiences on x86 boxes.
OSOL has some great features, and I agree with you about RPM and ZFS (personally, I consider the BSD ports setup to be the best of the current options).
My experience is simply that Linux is more stable. With OSOL I was constantly running into issues in all areas (day to day sysadmin work, package management, hardware, etc). I'm not saying OSOL sucks, I think it has great potential, but in the current state I find Linux to be more reliable and therefore the better choice.
I was working off the most recent release, but yeah, I know SPARC support is pretty new. I'm hoping it will get better in the future, but I've had so many issues even on x86 platforms that I'm not expecting a whole lot.
I'm typically an early adopter, so I'm not too concerned with having to do workarounds, rebuild packages, etc. But it seems that with OSOL I was running into more issues where I just couldn't find any workarounds, both in KB searches and in my own playing around.
There's some really great features, and I'd love to see it improve (I really do think it has a lot of potential), but at the moment, it just isn't there reliability-wise on any architecture (when compared to Linux).
I was recently tasked with doing an inventory and repurposing of a stack of older Sun machines (Sunfire, Netra, etc).
What I discovered is that OpenSolaris won't even install on some of the models. Install from CD? Nope. Install remotely via a network install? Nope, and let me go on record as saying that the network install process is *absurdly* complex.
On the other hand, I popped a Debian CD in, and it installed beautifully once I booted into expert mode and loaded fdisk (parted blows when dealing with Sun tables).
That's right, Linux was easier to work with on these Sun servers than OpenSolaris. OSOL has some really cool features (ZFS and DTrace, for example), and I've mucked around in it on my x86 boxes before, but overall Linux is still easier to work with in my experience, even on Sun servers.
I always keep an OSOL VM in VirtualBox, but it doesn't see much use. I'd rather use Linux or BSD.
When I purchased my netbooks early on, I could get them in Linux. When I convinced some family members to carry a netbook when they fly instead of a bulky laptop, I couldn't *find* one in stores with Linux. All the major retailers around here (BB, CompUSA, etc) carried a ton of different models and brands, but every single one in the store had XP installed. Now, that's not a major issue when I can just wipe XP and install Linux, but it is still annoying.
Slashdot Mirror
To my knowledge, it isn't a choice. I *had* to learn cursive 20 years ago in elementary school, my younger sisters *had* to learn it 4 years ago in elementary school.
We aren't given a choice, but as soon as we get out of school (or reach a grade where the teachers don't care), we quickly realize that print is so much easier than cursive.
Proper handwriting is all well and good, but if it takes noticeably longer to read my notes, screw it. Considering how little free time people have anymore, it doesn't make sense to waste one more second than you have to on reading. Print is more legible, therefore it will be the favored script.
It's not about whether or not learning to write matters, it is about one particular script. If print script is the only one taught, we are still teaching writing. We're just making the natural transition to a simpler script.
I see it as similar to, say, Russia deciding to only teach the romanized script instead of the old Cyrillic. They are still being taught to write, albeit in a different script.
I don't really see any computer-related cause. Cursive has declined for decades. We just don't care how pretty our words look on paper anymore. That was the whole appeal to cursive: adding unnecessary pen strokes to make the letters look nice.
Except there's a problem. When you don't write cursive regularly, your signed name eventually devolves into a wiggly line, which is completely useless from a forensic standpoint.
Most people write faster with print. Cursive and print are just form vs function. Cursive is pretty, and was all the rage back when people cared about penmanship. Print is utility, quick and dirty.
Well, a lot of people use a bastardized system like me: print letters with the bottoms joind (like cursive).
Printing the letters can actually be faster. Consider the letter 't'. In cursive (the way I was taught, at least), you start at the bottom, go up, then back down, then pick up the pen and cross it. In print, you start at the top, go down, pick up the pen and cross it. An entire stroke is cut out of the process.
Cursive has always been slower for me because of all the extraneous strokes it adds (think about the capital G and S, for example).
I've heard that it is fast, but I have always found cursive to be slow. Over time, I've adopted a sort of bastardized script. Normal printed letters joined at the bottom (a la cursive). Faster than plain print, since I don't lift the pen very often, and far more legible than cursive.
I like your concept of simplifying the writing style. Calligraphy can be beautiful, but I hate seeing a thousand needless loops in someone's day-to-day writing.
At 5.5 mil LOC, you'd be lucky if you could even *find* the source of one bug a day.
There is a balancing act involved. I remember an old chestnut that said something to the effect of "A product is good enough to release when it works for 85% of the people trying to use it". Go above 85%, and you start getting diminishing returns on cost. Could they fix every single little glitch? Sure. From a business perspective, is it worth the price? No way.
The whole point of the Mythical Man Month is not that more coders never means more productivity, it is that there is a balance point at which going beyond it does not increase productivity. 3 is better than 1, but 3000 is not always better than 1000. At this point, 32 is probably enough. Maintaining a codebase and adding new features requires a lot fewer devs than the initial development of the product. Most of the leg work (back-end, tool suite, etc) has already been completed.
Well yeah, in this case it isn't bad. I was referring more to the practice of just turning AU on and forgetting about it. If you're controlling when everything is pushed out from WSUS, I wouldn't really consider it "automatic" anymore.
Yup, when it comes to servers, the admin is more important than the OS. If the admin knows what he's working with, he can keep even the worst OS more or less secure.
We had a similar issue at work. Our servers were all working off a group policy that allowed AU. It was set up that way long before I started there. Sure enough, AU took down the mail server one day while forcing a reboot after a patch. Lesson learned.
The biggest threat to security is an admin who isn't intimately familiar with their systems. We've all been there at least once =)
I blame the admins there. If they aren't paying attention to vulnerabilities in their server packages, they're shitty admins. Windows servers are the same way. No admin worth the title runs AU on a production server, and they take just as long to patch their servers.
Not an OS problem, but a shitty admin problem.
The hardware isn't *that* old (6 years), but I'm not too worried about getting it fixed. Debian is running well and we're happy.
Yup. I just restored a laptop last month for one of our employees whose home ISP (Brighthouse) disconnected him until he could show them that the machine had been repaired.
I thought this was common practice among major ISPs. We've seen the same here at work, when we were contacted early this year when our ISP noticed some spam coming from our mail server.
Machine had 2 GB of RAM, so memory shouldn't be the issue. The CD drive had to be recognized since I was able to boot the Debian installer. The problem I ran into was an error during the install phase that couldn't be worked around.
Yeah, and I can understand the sentiment. It usually is one of the biggest problems. Windows users treating Linux like Windows, Python coders treating it like C++, etc. A lot of "newbie" issues with most things can probably be traced back to them just not realizing that they have to treat the new *whatever* as a different entity from what they are used to.
I spent a couple weeks on this issue. Looked at the HCL, the BigAdmin stuff, pored through Google and all the OSOL docs and ml archives I could find. I just happened to be unlucky and had a hardware config that I couldn't tweak into working. Just one of the perils of early adoption =)
Yup, I always have a FreeBSD guest installed in VirtualBox. I've always like the BSD distros, mainly for the reason you mentioned (getting the best of both worlds...old-school Unix and Linux).
Yup, it has definitely improved. Another year or two with the right focus and it could be really useful. I'll continue to keep an updated install in VirtualBox for testing (I agree about hardware issues). Of course, VirtualBox has its own issues with OSOL (building the guest tools really mucked things up, but I blame VB for that, not OSOL).
My first experience outside MS was actually in Solaris, and I migrated to Linux later. I'm familiar enough with Solaris from my early days that I understand it has to be treated differently.
And yeah, I'd been through the HCL and knew that this particular model wasn't supported. But I also know that HCL's aren't always comprehensive and you can sometimes get away with installs on other hardware with a little tweaking.
I'm not saying OSOL is bad, I really do love some of the features, I just don't find it to be better than Linux (in a general sense, I'll agree that some aspects *are* better) in its current state. In the future, who knows. With the right work, it could be a great alternative.
I haven't tried vanilla Solaris, and we didn't currently have any Solaris media (we're mainly an MS shop with a handful of Linux servers/VMs and Xserves...though I'd prefer the reverse *grin*)
These machines aren't intended for production use anytime soon. We're using them now just to play around, get familiar with the hardware, poke around in the apps. Mainly just prep work in the event that we need to support Sun machines for a client sometime in the future.
I haven't tried it on a diskless system, but I didn't really have any issues installing Debian on the Sunfire servers (all were headless).
Started the install through the serial port, configured SSH and did the rest through an SSH conn (serial is just too painful on the eyes *grin*)
I can't speak for all distros, but I've found serial setups to be fine in both Debian and Gentoo (my two primary distros over the past 8 years).
The OSOL install isn't really *bad* up to the point where it failed (though I really have complaints with the network install process), I just ran into the issue of trying to install it on SPARC hardware that wasn't yet supported in OSOL. I come from being an early Gentoo user doing Stage 1 builds. Consoles and serial port installs don't bother me a bit, and I'm sure the install process will get better as time goes on and support is improved =)
Aye, deb packages aren't bad, and I've had good experiences with Gentoo's portage setup (though that seems to have gone downhill the last couple years). RPM is my least favorite of the major package formats, though I may just be biased from my memories of RH and dependency hell years ago *grin*
Well, I couldn't even get OSOL installed on the SPARC machines, so my experience on that side comes from my experiences on x86 boxes.
OSOL has some great features, and I agree with you about RPM and ZFS (personally, I consider the BSD ports setup to be the best of the current options).
My experience is simply that Linux is more stable. With OSOL I was constantly running into issues in all areas (day to day sysadmin work, package management, hardware, etc). I'm not saying OSOL sucks, I think it has great potential, but in the current state I find Linux to be more reliable and therefore the better choice.
I was working off the most recent release, but yeah, I know SPARC support is pretty new. I'm hoping it will get better in the future, but I've had so many issues even on x86 platforms that I'm not expecting a whole lot.
I'm typically an early adopter, so I'm not too concerned with having to do workarounds, rebuild packages, etc. But it seems that with OSOL I was running into more issues where I just couldn't find any workarounds, both in KB searches and in my own playing around.
There's some really great features, and I'd love to see it improve (I really do think it has a lot of potential), but at the moment, it just isn't there reliability-wise on any architecture (when compared to Linux).
I was recently tasked with doing an inventory and repurposing of a stack of older Sun machines (Sunfire, Netra, etc).
What I discovered is that OpenSolaris won't even install on some of the models. Install from CD? Nope. Install remotely via a network install? Nope, and let me go on record as saying that the network install process is *absurdly* complex.
On the other hand, I popped a Debian CD in, and it installed beautifully once I booted into expert mode and loaded fdisk (parted blows when dealing with Sun tables).
That's right, Linux was easier to work with on these Sun servers than OpenSolaris. OSOL has some really cool features (ZFS and DTrace, for example), and I've mucked around in it on my x86 boxes before, but overall Linux is still easier to work with in my experience, even on Sun servers.
I always keep an OSOL VM in VirtualBox, but it doesn't see much use. I'd rather use Linux or BSD.
I'll confirm what the others have said.
When I purchased my netbooks early on, I could get them in Linux. When I convinced some family members to carry a netbook when they fly instead of a bulky laptop, I couldn't *find* one in stores with Linux. All the major retailers around here (BB, CompUSA, etc) carried a ton of different models and brands, but every single one in the store had XP installed. Now, that's not a major issue when I can just wipe XP and install Linux, but it is still annoying.
Sounds pretty appealing sometimes. But can I come back as a goober fish instead, so I can kill Jar-Jar?
Though you just *had* to mention jellyfish. Now I'm gonna have the song Mental Floss stuck in my head all night =)
"They're just simple protoplasm, clear as cellophane,
They ride the winds of fortune, life without a brain."
So what happens if I'm afraid of spiders *and* I like video games? I'm born androgynous? =)