That wasn't in Colorado, was it?
Oh wait, never mind... that was just slightly different...
Friend of mine worked installing mobile homes for a while, years ago, and caught a guy about to weld the ground for a house's electrical service to the same house's gas line...
This is what Google is for. Pretend that everything you post online will live forever, and bear that in mind as you put it there... and you'll be close enough to reality to make no odds.
I'll actually go one step further on that: make personal connections. Think about anyone you know reasonably well who is in the field. Use them as resources. I got my first programming job via a friend of mine; you may say "nepotism", but think about it this way: if you're gonna hire someone, would you rather have one of your employees vouch for them, or have to rely solely on the impression you've gotten by chatting for an hour or two?
I've recently found myself job-hunting again, for the first time in ten years. While I am indeed going on an interview today, after having been called by a recruiter when he saw my resumé on Dice, I have four strong leads - one of which is for my "dream job" - and all of those came by contacting people I know.
Things I can mention that have worked very well for me:
Participate in open-source projects - even just at the bug-fixing level. If you search Google for my name in quotes (and prospective employers will!), nearly every hit on the first four pages is me, despite sharing a name with a NASCAR driver and a judge in a prominent civil-rights case. The majority of those hits are mailing list posts I have made.
Go to trade shows, if you can possibly manage it. Some of them offer a reduced rate if you're paying your own way, and obviously some of them (i.e., LinuxTag) are quite affordable (possibly excepting travel!) If you have any idea what you would like to specialize in, this gives you the opportunity to meet the "people behind the code", which - let me tell you - is one of the strongest "ins" that you can hope for.
Spend some wetware cycles on software design! I can't tell you how many people I've worked with who are sharp, smart coders... and can't write a clean API to save their life. Hiring managers really, really like this. My recommendation there is - at the risk of "drinking the cool-aid" - going and studying the Qt or KDE source code and design guidelines. Even if you're not intending to be a C++ programmer. I've not looked hard at KDE, but Qt is some of the cleanest code from the standpoint of API design and modularity that I've ever seen. (I'm not necessarily talking about the code inside a module - some of that is pretty grody, but that happens on a project that big.)
Lastly, I suggest striking a balance between specialization and still being very flexible. As an example, I worked at Maxtor for many years. When things started getting ugly from the work-environment perspective, I kept talking about leaving. Most people - particularly, say, servo engineers - generally responded with, "Where are you gonna go? Seagate's not hiring." My response was, "Hey, I'm an applications programmer. I don't care what's at the other end of the cable - I don't even care if there is a cable!" Basically, the servo engineers got paid a fair bit more... but I have a much, much easier time finding a job - and have never been laid off, short of the company going under.
Applying "slippery slope" to that logic, then if the secretary to the manager of the Widget Reshuffling Department within the FBI steals a car, then it's the taxpayers' faults, because ultimately the chain of command leads to someone The People(tm) elected??
There are two things, in my experience, that are holding Linux - and indeed, the majority of open-source projects - back.
Firstly (in no particular order) is that documentation is generally nonexistent, inadequate, outdated, or even actively misleading. When this isn't the case, it's too frequently written from the viewpoint of someone who already knows exactly what they want to do, they have just forgotten where the button is. I've been using computers for thirty years (running just about every common OS there's been over that time period), and programming for most of that - and I still come across too many cases where they're using a different term than I would have used, and thus it ends up being a steeplechase to try to figure out how to do what I'm after. I also am frustrated at how often I need to try going to the documentation in the first place - if it's a simple, frequently-performed task, it should be fairly intuitive, which would indicate that after as long as I've been using computers, I should be able to figure it out!
The other downfall I've come across is a "complexity gap" - Linux is, in my experience, fine for a beginning user, and okay for a gearhead... but the people in between are kind of screwed. The basic stuff "just works", and if you are willing to hack scripts or compile code, you can do just about anything - but all too often, if you need to do something even just a little past the basic stuff, you *have* to start hacking scripts.
ObStdDisc: I work for the company I mention here... but suffice it to say that I left a very stable job to do so - so's to indicate that I do actually believe in the excellence of the product.
Keep an eye on Rebit. It doesn't do what you're asking about as of this moment... but (without treading into realms of "I'm not allowed to talk about that") I can safely say that the future holds some interesting things along this sort of direction.
I'd suggest that, instead of using a laptop, he aims for an older desktop system - say, a '486 class machine.
Older computers are much simpler, from both a physical and an electronic standpoint - fewer layers in the boards, fewer transistors in the chips, etc.
There are still many, many Apple ]['s still in good working order; I know for a fact that the computer I learned to program on (an original Apple ][, not even a ][+) is not only still working, but has been powered 24/7 for years, running the X10 system for its current owner's house. That means it's been being *used* for (almost exactly) thirty years...
A bit of explanation: my background for most of the last ten years has been in building frameworks that get mostly used by others - specifically, applications/libraries that get used to write tests and/or build field tools for hard disk drives. An awful lot of this was "oh shit" sort of work - someone comes running to my group after discovering an issue on a product after it's shipped, and they need a tool to fix the problem, and they need it a week ago. So a lot of my designs grew out of the need for extremely flexible code that could be repurposed quickly - in other words, the ultimate in code reuse and modularity. Most of it also needed to run on three different OS families (and they would have liked a couple more).
Here are the ones that I try to follow; most of them apply to design of just about anything, not just code:
0) Using performance as a reason to bypass any of the following rules is acceptable only once you've demonstrated a problem with a profiler. "Programmers are notoriously bad at predicting how their programs actually perform."
1) Decide before you start what toolboxes you're going to require. Invest (money, time, whatever) in the best tools you can afford. If you have to spend time wondering whether your tools are broken, you've probably chosen poorly.
2) Spec your functionality, then design your public interface. Write to the interface. Do your damndest not to change that interface after you "ship" your module.
3) Do not include anything in your interface that falls outside the toolboxes you've selected in item 1.
4) Decouple your modules. I cannot possibly over-emphasize this. No "convenience exceptions"; the time you save by tying two modules together will be lost the moment one of them needs to get used somewhere you didn't plan for... and you *will* need to.
5) Along with decoupling, try to keep your functions as general as possible (but see also rule 0). It's a bit more work to write a general-case function than a specific one, but when you end up needing a variant of that function later, you'll be glad you did.
6) When possible, write portable code; you never know when you'll need it to run somewhere else. This also provides you the ability to use additional debugging tools that might not be available to you on your first platform. How to accomplish this is a topic worth its very own list...
7) Pivot the world around configuration files. That doesn't necessarily mean a file on the end-user's drive - it can mean a compiled-in source file which configures the program's behaviour. But don't hard-wire it into the function.
My high-range hearing is indeed not what it once was, at the *ahem* ripe old age of 32. I can no longer hear dogwhistles.
And yes, that means that there are some businesses that I do not frequent because of "ultrasonic" burglar alarms and the like. This would merely add one more reason and group of businesses.
Beware making over-broad generalizations about what people can or cannot sense, the way that their bodies behave psychopharmacologically, even where organs are placed within the body... in short, everybody's different. Duh! Isn't that what they taught us as very young people? So why are so few people willing to believe it?
On a current-model 7200RPM SATA drive, you can expect to see around 80MB/sec at the outer edge of the disk. And the rule of thumb is, you see half that at the inner edge, and three-quarters in the middle. So call it a (nearly) guaranteed 40MB/sec, and an average of 60MB/sec.
These are not hard-and-fast numbers, but it's a pretty good estimate for a modern drive.
And that is - and always will be - true for some people. There is a market, certainly, for both hybrid and flash - and the storage people agree.
It's just like the SCSI vs. ATA question a few years ago: if you need performance, you went SCSI, and if you needed cheap and big, you went ATA. I don't see that division going away, and I don't see either hard disk or flash technology changing in such a way as to bridge that gap.
That depends on what country you're in. In the United States, it's perfectly doable. In Germany, however, you're not allowed to sign away copyright. I did some research to this regarding code contributions to Qt; their dual-licensing scheme means that it's insufficient for you to license the code to them. They actually need to own the code.
I'm here to tell you, it ain't that easy - packaging is the least of the issues. Have you tried to build a binary that "just works" on a system other than the one you're sitting at? No console apps, please. Let's talk about X11. Hell, let's talk about GTK or Qt!
Have you investigated symbol versioning? Hope you've got a nice five-year-old glibc to compile against...
Or you could use the LSBSDK and try and do it that way. Have fun - it's still very much under development. The people behind it are great and very helpful... but (especially if you're using C++ instead of just straight C) I almost guarantee you'll run into problems.
I love Linux, don't get me wrong. But the rule everyone seems to keep forgetting here is: "All hardware sucks, all software sucks". I've spent quite a lot of time recently trying to accomplish a "distro-agnostic" binary... and I wish you luck, sir.:)
Disclaimer: I work for a company that sells disks, sounds like "fee rate":)
That said, there are some noticeable differences between SAS and SCSI. What Google was looking at in that study, IIRC, was hard failures (read, "dead drive") - not simply marginal sectors and the like.
One big difference, off-hand, is that SAS/FC disks are usually written at a lower areal density ("bits per inch") than a SATA drive. Consumer-grade drives are all about the capacity, so the design team will push the areal density as high as is still manufacturable. For a SAS or FC drive, reliability is the key... so doing things like writing at a lower bit density, adding extra ECC, and such are okay.
Advertised error rates on a desktop drive are usually on order 1 bit in 10-12; the latest SAS drive I saw a press release on advertises less than 1 in 10-16 bits.
There's more, but those are the big ones I can think of off-hand.
I can speak with some authority on this - I work for one of those aforementioned hard-drive manufacturers, and have been doing a small amount of work on this exact thing.
The easy answer is this: in order to do ECC-like data checking on a larger set of data (say, a group of eight 512-byte sectors), it means that if you want to write sector three of that eight, you end up having to re-read the whole thing before you do anything else - thus basically giving you 4,096-byte "sector" anyway.
The other half of that answer is this: do you know what the "real" storage capacity of a CD is, without all the error checking? It's a bit less than double. Even most of the enterprise folks wouldn't accept a 40% hit in data density in return for what works out to not that big an increase in reliability (data redundancy doesn't buy you that much unless that data is on different spindles). They'd just rather get the whole data space and do a RAID, especially since that's what they're going to do anyway.
That's simple: by the time you can build one of these, you can probably also build a microbot with a miniature camera in it. You just wear goggles, and you view what the microbot sees.
Your frame of reference would be off (well, at least it would be if you're smart and don't have the thing hovering right above you) but you'd get video.
Don't confuse asocial with anti-social... there is a significant difference.
What you're describing is asocial - that is, not desiring to participate in society. Antisocial, on the other hand, carries the implication of being actively harmful to society, not just avoiding it.
Yes, "anti-social" gets used that way a lot - hence the (fairly recent) addition of that first definition listed - but I, at least, feel that it's an important distinction.
The interesting follow-up experiment would be to attempt to figure out which people still don't pay (with a hidden camera elsewhere?) and see if you can find psychological traits in common. I suspect that you'd find some reasonable basis for mild sociopathy amongst those people - the people in whom the "I'm being watched" is then overriden by "nope, they're fake" and goes on to do something antisocial anyway.
My wife and I have custom matching wedding rings in white gold; this is admittedly almost a necessity for me (I'm 6'4" but wear a 7 1/2 ring. I have spider fingers.)
Neither of us are particularly impressed by white diamonds, about the only ones you can get regularly. (We both loved the Colorado golden diamonds we saw - but De Beers will only let them sell something like ten a year.) But we both collect gems and minerals...
So, my ring has an alexandrite in it (and no, it's a real one, not a lab-grown modified sapphire) and hers has a tsavorite (green garnet; looks like emerald but brighter and not brittle like emerald).
And yeah, they cost us more than a month's salary... but unlike diamonds, our stones are actually worth it.
Slashdot Mirror
That wasn't in Colorado, was it? Oh wait, never mind... that was just slightly different... Friend of mine worked installing mobile homes for a while, years ago, and caught a guy about to weld the ground for a house's electrical service to the same house's gas line...
Or perhaps US HPalm3Compaquipspring Corporation...?
This is what Google is for. Pretend that everything you post online will live forever, and bear that in mind as you put it there... and you'll be close enough to reality to make no odds.
I'll actually go one step further on that: make personal connections. Think about anyone you know reasonably well who is in the field. Use them as resources. I got my first programming job via a friend of mine; you may say "nepotism", but think about it this way: if you're gonna hire someone, would you rather have one of your employees vouch for them, or have to rely solely on the impression you've gotten by chatting for an hour or two?
I've recently found myself job-hunting again, for the first time in ten years. While I am indeed going on an interview today, after having been called by a recruiter when he saw my resumé on Dice, I have four strong leads - one of which is for my "dream job" - and all of those came by contacting people I know.
Things I can mention that have worked very well for me:
Good luck!
Applying "slippery slope" to that logic, then if the secretary to the manager of the Widget Reshuffling Department within the FBI steals a car, then it's the taxpayers' faults, because ultimately the chain of command leads to someone The People(tm) elected??
There are two things, in my experience, that are holding Linux - and indeed, the majority of open-source projects - back. Firstly (in no particular order) is that documentation is generally nonexistent, inadequate, outdated, or even actively misleading. When this isn't the case, it's too frequently written from the viewpoint of someone who already knows exactly what they want to do, they have just forgotten where the button is. I've been using computers for thirty years (running just about every common OS there's been over that time period), and programming for most of that - and I still come across too many cases where they're using a different term than I would have used, and thus it ends up being a steeplechase to try to figure out how to do what I'm after. I also am frustrated at how often I need to try going to the documentation in the first place - if it's a simple, frequently-performed task, it should be fairly intuitive, which would indicate that after as long as I've been using computers, I should be able to figure it out! The other downfall I've come across is a "complexity gap" - Linux is, in my experience, fine for a beginning user, and okay for a gearhead... but the people in between are kind of screwed. The basic stuff "just works", and if you are willing to hack scripts or compile code, you can do just about anything - but all too often, if you need to do something even just a little past the basic stuff, you *have* to start hacking scripts.
ObStdDisc: I work for the company I mention here... but suffice it to say that I left a very stable job to do so - so's to indicate that I do actually believe in the excellence of the product.
Keep an eye on Rebit. It doesn't do what you're asking about as of this moment... but (without treading into realms of "I'm not allowed to talk about that") I can safely say that the future holds some interesting things along this sort of direction.
I'd suggest that, instead of using a laptop, he aims for an older desktop system - say, a '486 class machine.
Older computers are much simpler, from both a physical and an electronic standpoint - fewer layers in the boards, fewer transistors in the chips, etc.
There are still many, many Apple ]['s still in good working order; I know for a fact that the computer I learned to program on (an original Apple ][, not even a ][+) is not only still working, but has been powered 24/7 for years, running the X10 system for its current owner's house. That means it's been being *used* for (almost exactly) thirty years...
A bit of explanation: my background for most of the last ten years has been in building frameworks that get mostly used by others - specifically, applications/libraries that get used to write tests and/or build field tools for hard disk drives. An awful lot of this was "oh shit" sort of work - someone comes running to my group after discovering an issue on a product after it's shipped, and they need a tool to fix the problem, and they need it a week ago. So a lot of my designs grew out of the need for extremely flexible code that could be repurposed quickly - in other words, the ultimate in code reuse and modularity. Most of it also needed to run on three different OS families (and they would have liked a couple more).
Here are the ones that I try to follow; most of them apply to design of just about anything, not just code:
0) Using performance as a reason to bypass any of the following rules is acceptable only once you've demonstrated a problem with a profiler. "Programmers are notoriously bad at predicting how their programs actually perform."
1) Decide before you start what toolboxes you're going to require. Invest (money, time, whatever) in the best tools you can afford. If you have to spend time wondering whether your tools are broken, you've probably chosen poorly.
2) Spec your functionality, then design your public interface. Write to the interface. Do your damndest not to change that interface after you "ship" your module.
3) Do not include anything in your interface that falls outside the toolboxes you've selected in item 1.
4) Decouple your modules. I cannot possibly over-emphasize this. No "convenience exceptions"; the time you save by tying two modules together will be lost the moment one of them needs to get used somewhere you didn't plan for... and you *will* need to.
5) Along with decoupling, try to keep your functions as general as possible (but see also rule 0). It's a bit more work to write a general-case function than a specific one, but when you end up needing a variant of that function later, you'll be glad you did.
6) When possible, write portable code; you never know when you'll need it to run somewhere else. This also provides you the ability to use additional debugging tools that might not be available to you on your first platform. How to accomplish this is a topic worth its very own list...
7) Pivot the world around configuration files. That doesn't necessarily mean a file on the end-user's drive - it can mean a compiled-in source file which configures the program's behaviour. But don't hard-wire it into the function.
My high-range hearing is indeed not what it once was, at the *ahem* ripe old age of 32. I can no longer hear dogwhistles.
And yes, that means that there are some businesses that I do not frequent because of "ultrasonic" burglar alarms and the like. This would merely add one more reason and group of businesses.
Beware making over-broad generalizations about what people can or cannot sense, the way that their bodies behave psychopharmacologically, even where organs are placed within the body... in short, everybody's different. Duh! Isn't that what they taught us as very young people? So why are so few people willing to believe it?
(ObDisclaimer: I work for Seagate.)
On a current-model 7200RPM SATA drive, you can expect to see around 80MB/sec at the outer edge of the disk. And the rule of thumb is, you see half that at the inner edge, and three-quarters in the middle. So call it a (nearly) guaranteed 40MB/sec, and an average of 60MB/sec.
These are not hard-and-fast numbers, but it's a pretty good estimate for a modern drive.
(ObDisclaimer: I am employed by Seagate.)
And that is - and always will be - true for some people. There is a market, certainly, for both hybrid and flash - and the storage people agree.
It's just like the SCSI vs. ATA question a few years ago: if you need performance, you went SCSI, and if you needed cheap and big, you went ATA. I don't see that division going away, and I don't see either hard disk or flash technology changing in such a way as to bridge that gap.
That depends on what country you're in. In the United States, it's perfectly doable. In Germany, however, you're not allowed to sign away copyright. I did some research to this regarding code contributions to Qt; their dual-licensing scheme means that it's insufficient for you to license the code to them. They actually need to own the code.
I'm here to tell you, it ain't that easy - packaging is the least of the issues. Have you tried to build a binary that "just works" on a system other than the one you're sitting at? No console apps, please. Let's talk about X11. Hell, let's talk about GTK or Qt! Have you investigated symbol versioning? Hope you've got a nice five-year-old glibc to compile against... Or you could use the LSB SDK and try and do it that way. Have fun - it's still very much under development. The people behind it are great and very helpful... but (especially if you're using C++ instead of just straight C) I almost guarantee you'll run into problems. I love Linux, don't get me wrong. But the rule everyone seems to keep forgetting here is: "All hardware sucks, all software sucks". I've spent quite a lot of time recently trying to accomplish a "distro-agnostic" binary... and I wish you luck, sir. :)
Disclaimer: I work for a company that sells disks, sounds like "fee rate" :)
That said, there are some noticeable differences between SAS and SCSI. What Google was looking at in that study, IIRC, was hard failures (read, "dead drive") - not simply marginal sectors and the like.
One big difference, off-hand, is that SAS/FC disks are usually written at a lower areal density ("bits per inch") than a SATA drive. Consumer-grade drives are all about the capacity, so the design team will push the areal density as high as is still manufacturable. For a SAS or FC drive, reliability is the key... so doing things like writing at a lower bit density, adding extra ECC, and such are okay.
Advertised error rates on a desktop drive are usually on order 1 bit in 10-12; the latest SAS drive I saw a press release on advertises less than 1 in 10-16 bits.
There's more, but those are the big ones I can think of off-hand.
I can speak with some authority on this - I work for one of those aforementioned hard-drive manufacturers, and have been doing a small amount of work on this exact thing.
The easy answer is this: in order to do ECC-like data checking on a larger set of data (say, a group of eight 512-byte sectors), it means that if you want to write sector three of that eight, you end up having to re-read the whole thing before you do anything else - thus basically giving you 4,096-byte "sector" anyway.
The other half of that answer is this: do you know what the "real" storage capacity of a CD is, without all the error checking? It's a bit less than double. Even most of the enterprise folks wouldn't accept a 40% hit in data density in return for what works out to not that big an increase in reliability (data redundancy doesn't buy you that much unless that data is on different spindles). They'd just rather get the whole data space and do a RAID, especially since that's what they're going to do anyway.
The thunderous applause is merely a canned track...!
Not only have we forgotten why, but enough never knew in the first place...
That's simple: by the time you can build one of these, you can probably also build a microbot with a miniature camera in it. You just wear goggles, and you view what the microbot sees.
Your frame of reference would be off (well, at least it would be if you're smart and don't have the thing hovering right above you) but you'd get video.
Don't confuse asocial with anti-social... there is a significant difference. What you're describing is asocial - that is, not desiring to participate in society. Antisocial, on the other hand, carries the implication of being actively harmful to society, not just avoiding it. Yes, "anti-social" gets used that way a lot - hence the (fairly recent) addition of that first definition listed - but I, at least, feel that it's an important distinction.
Oh, but What about those of us who like yyyy-mm-dd? None of the others sort properly...
I know at least one installation that's using an Acorn-based fluorometer system... I'd forgotten about Acorns, until a friend of mine mentioned it!
The interesting follow-up experiment would be to attempt to figure out which people still don't pay (with a hidden camera elsewhere?) and see if you can find psychological traits in common. I suspect that you'd find some reasonable basis for mild sociopathy amongst those people - the people in whom the "I'm being watched" is then overriden by "nope, they're fake" and goes on to do something antisocial anyway.
...then it's exactly what you need in order to make this work. [Stop- HAMR time.]
My wife and I have custom matching wedding rings in white gold; this is admittedly almost a necessity for me (I'm 6'4" but wear a 7 1/2 ring. I have spider fingers.)
Neither of us are particularly impressed by white diamonds, about the only ones you can get regularly. (We both loved the Colorado golden diamonds we saw - but De Beers will only let them sell something like ten a year.) But we both collect gems and minerals...
So, my ring has an alexandrite in it (and no, it's a real one, not a lab-grown modified sapphire) and hers has a tsavorite (green garnet; looks like emerald but brighter and not brittle like emerald).
And yeah, they cost us more than a month's salary... but unlike diamonds, our stones are actually worth it.
Yeah, so am I a verified member. All that means is that you have a bank account.
--
Make Money on the 'Net