The black box system does tell you that, in some cases at least. And it says that the driver is slamming their foot on the gas. I tend to believe the black box - but it's based on the same sensors and software that's supposedly at fault...
You'll want insurance. Also, you'll want insurance coverage without any break in it, ideally, or you can hit a range of problems.
There are several ways to do that. If you're really setting up on your own then you're already looking at incorporating or setting up as an LLC. As part of that, talk to a local business insurance broker about various things, including health insurance.
If you're a professional, check with your professional associations. The IEEE (which is a great organization for engineers, software or otherwise) offers group insurance to members, for example.
If your skills are individually valuable, rather than being a commodity, consider working part time for either your previous employer or a random startup. There are other advantages to doing that as you set up on your own (peers to bounce ideas off, access to resources, actual income) but group health insurance is one of them.
Don't skimp on preventative care - dental and optical in particular. If you're young and healthy and don't have kids then you can skimp on the health coverage, going for a high deductible plan and doing the risk modeling yourself - a common thing for individual insurance, which can be very expensive otherwise. But if you have kids, or are thinking about it, don't do that.
And, once you've asked slashdot, talk to your spouse. Unless (s)he is on the same page about this, as well as everything else about setting up on your own, then you're well and truly fucked, both in relationship and business terms.
Windows 7 can still be targeted by a IE bug that's been in place since IE6. Safari doesn't have zero day bugs *that* old
How would you know? Zero-day means a non-public exploit.
Safari was released in early 2003.
Internet Explorer 6 was released in August 2001.
So the unfixed Internet Explorer bugs have been around quite a bit longer than Safari has. So Safari is unlikely have any bugs older than this IE bug, zero-day or otherwise.
(OK, there could be crusty KHTML era bugs left in the Safari code-base, but there's not much of that code left untouched)
64 bit binaries consume more space than 32 bit binaries. That means they make less effective use of system memory and (just as importantly) CPU cache.
All other things being equal, a 64 bit binary will run slower, while using more system resources than a 32 bit binary, so it's something that you'd only want to do if you could actually make use of huge amounts of memory in your application directly.
All other things aren't equal, though, as x86 is rather a "special" architecture. There the 64 bit binary will get access to (amongst other things) more registers. It'll still consume more system resources (ram, disk, power), but may run faster, or slower.
So it's not as simple as "64 bit good, 32 bit bad".
Odd. I have much the same perspective as you, but with VHDL and Verilog reversed. I see Verilog as being slightly closer to hardware and VHDL as a little better matched to architectural modelling. I suspect it depends on the tools and workflow you get used to more than anything intrinsic to either language.
You can certainly make the "being a software developer" mistake in either language - I don't think that's a reason to choose one over the other, rather it's just something to be very aware of.
Your job is not to be an advocate, it's to support your users to the best of your ability. That means steering them towards stuff you know how to support, but doesn't mean pushing them towards your favorite hobby OS when that's not a good match for them.
The most important thing is to support what your users need to do. For creative users, including writers, that means the tool they're familiar with. If they're used to Windows and Windows tools, give them Windows. If they're used to OS X, give 'em a Mac. Either way, give them a usable screen and a good keyboard - writers will likely kill you if their main writing machine has a plasticky 93% size keyboard.
The second most important thing is to make sure that the systems are available and the data is safe. Which makes Windows a PITA to support if you're not familiar with Windows administration (which is what it sounds like).
If it were me, I'd use Macbook Pros running OS X, with VMWare Fusion with unity mode turned on allowing me to run Windows (or Linux, come to that) applications, as though they were native apps. (Don't skimp on RAM). That way the machines can be shared by users who prefer different apps to do what they do, and you can take advantage of either the OS X level stuff or the underlying unix to do backups.
And a couple of cheap netbooks for emergencies, email, throwing in the back of a truck, that sort of thing. Then a bunch of robust, cheap media for ad-hoc backups (USB sticks, CD-Rs).
But I'm not your users. Ask them what apps they need, then work out how best to support them.
You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.
It's possible to write secure code in PHP, but almost nobody does, and most of the PHP code that you can acquire easily is painfully insecure. A never ending race to patch a never ending series of holes means you've already failed at security. Depending on "white-hat hacking", ditto.
Other than that... security is something integrated process, starting with the architectural design, the implementation and the processes around it, documentation and maintenance. It's not something you can just add on the side.
Books? No idea, but looks for stuff that talks about the entire lifecycle, and that comes from real world experience.
Oh, and learn some real crypto, so you can avoid both the snake oil and the irrational paranoia.
You don't know what "marginal cost" means, do you?
It means the cost to create one extra item of something, once you're already making a bunch of them. In the case of software it's the distribution cost.
That tends to be extremely low for any software product (which is why we seldom get manuals in the box now, as they add a lot to the marginal cost) and is close to zero for online distribution. Even if you're paying through the nose for bandwidth your incremental cost for a CD size.iso is a few pennies. If you use something like bittorrent, to leach off your users bandwidth (I'm looking at you, Blizzard), your incremental cost is likely an order of magnitude or two less than that.
I don't disagree much with this, but I think it can be expressed much more concisely as "I'm old. I want games to be just like my rosy memories of games when I was young, maybe prettied up a bit."
That depends. One of the obvious ways to do this is simply to steal the boards that failed burn-in testing and resell them.
Those boards will mostly work, except for when they don't. Symptoms for the end user could be random crashes, failing to work with some speeds of RAM or CPU or only running for 10 minutes before crashing.
There are a few reasons for that. The minor ones are that most C++ / ObjC projects are big enough that it's difficult to bring an experience programmer in to work on them for just a few weeks, let alone someone with no large project experience. Not impossible, by any means, but not something that a larger company is likely to do outside of a more formal (and longer term) sponsorship arrangement.
The big reasons are that the absolute _last_ thing you need either on your resume, or to enhance your skill set is a brief job coding. The basic coding is something that you should be picking up the basics of in college, rounding out a little with some personal coding (helping out with the countless open source projects out there, for instance) and won't really bring to fruition until you're doing it full time.
The skills you're less likely to pick up there, but which you can pick up in a shorter temporary project are things like QA, marketing, sales, system administration, maybe even customer support. So look at picking up a grunt work job in the field that's not directly touching code. QA and testing (for a real software company, not EA or anything in that field) is a gig you might well be able to pick up, and which would teach you more about good software design and good software project management in a painful 8 weeks than you'd learn in a year writing software. If you can do that in an early-stage startup, and see that business process too, at least from the sidelines, even better.
Heck, if you could wangle it, working as a gopher for one of the Sand Hill Rd VC firms would be one of the best introductions to a career in the software field, I think.
The PDF is 326,093 bytes. The HTML is 184,296 bytes, and pulls in an additional 74,847 bytes in associated files, leading to a total download of 259,143 bytes. So, you're saving about 20% by going for the malformed, painful to read version. Time to read first page is probably comparable, if you're using a browser with adequate PDF support (which if your browser dates from the same era as your 14.4k modem, it probably doesn't).
Of course, with the HTML you also have the option of throwing away all the formating and reading it in lynx, saving yourself about 43% over the PDF.
Or you could just read the slashdot thread about it, and get the salient points in a mere 50k, plus images, flash ads and so on.
The content looks OK, but whatever app they used to convert from TeX to HTML not only produces ugly code that gives Frontpage a run for it's money, it also didn't close the <address> tag near the top, making the entire document right justified and italic.
Horribly broken HTML in a bunch of respects. Stick with the PDF version.
The article has this so wrong that it's not even funny.
DKIM has pretty much nothing to do with phishing, and will do absolutely nothing to make phishing more difficult (though you could build some sorts of phish defenses based on DKIM I wouldn't bet on them being very effective, and they're certainly not what DKIM was really designed for).
DKIM is designed to allow the sender of a piece of email to cheaply embed a cryptographic signature in the mail to prove that they sent the mail. It's not usually used at the end-user level, rather a consumer ISP might sign all the mail coming from their smarthost or a company sending a newsletter may sign that email using their domain, even though they're sending it out via their ISP or via an ESP.
That signature doesn't mean anything other than I take responsibility for this email.
That has two uses that are (mildly) related to spam or phishing. The first is that it means that when you get a piece of email and hit the "this is spam" button it's easy for your ISP to work out who to send the feedback report to.
The second is a bit more subtle. It allows a sender of email to attach a persistent identity to the mail they send, in a way that can't be spoofed by others and which is independent of the IP address the mail comes from. That allows receiving ISPs to accurately track the reputation of senders of email, tied to that DKIM identity. If, say, Cisco signs all their newsletters with DKIM, and I as an ISP haven't seen customers complain about that DKIM signed mail from Cisco then when this new email arrives Cisco I can be pretty sure that my customers won't complain about that, either. I can avoid some expensive content based spam filtering, deliver the mail directly to the inbox and avoid false positives.
Note that I don't give that mail that red carpet treatment because it is DKIM signed - I do so because the DKIM signature proves that it comes from a sender that I've decided to trust because of their good behaviour in the past. You can think of it as kind of like a cryptographically signed "From" address, if you like, or as an identity that receivers can use to track reputation that's more convenient to receivers and senders than peer IP address.
Why not S/MIME or PGP? Well, DKIM can be cheaper to sign and check than either, but the real reason is that DKIM doesn't change the body of the email at all - just adds a few headers - so it doesn't require any special changes to the recipients mail client to be readable, and doesn't leave ugly detritus in non-DKIM aware clients. (The tradeoff of that is that DKIM is slightly fragile - some forms of body modification in transit will break the signature - but that's OK, as DKIM isn't designed to work 100% of the time, and if the signature breaks the mail will just be treated on it's merits, without the benefit of additional history).
DKIM will be (and is) used by spammers, of course, but it won't buy them anything other than making it easier for ISPs to track their reputations. And, in the case of spammers, that's a bad reputation (so they'll likely cycle through lots of identities in DKIM, just as they do everywhere else, to leave that bad reputation behind them). But it only provides advantages to the sender of the mail if they use a consistent DKIM identity over the long term, and consistently send mail recipients don't object to.
dkim.org has all the technical info and suchlike on DKIM.
The OLPC also has a vastly smaller display (7.5" ?), small (256k) main memory and tiny (1 gig) permanent storage and, I think, a 15Wh batter (as compared to four times that in a typical laptop).
Those are possibly decent engineering tradeoffs to ship a cheap system with adequate battery life, but in terms of usability they're pretty crappy compared to second-hand laptops from a couple of generations back.
Slashdot Mirror
The black box system does tell you that, in some cases at least. And it says that the driver is slamming their foot on the gas. I tend to believe the black box - but it's based on the same sensors and software that's supposedly at fault...
You'll want insurance. Also, you'll want insurance coverage without any break in it, ideally, or you can hit a range of problems.
There are several ways to do that. If you're really setting up on your own then you're already looking at incorporating or setting up as an LLC. As part of that, talk to a local business insurance broker about various things, including health insurance.
If you're a professional, check with your professional associations. The IEEE (which is a great organization for engineers, software or otherwise) offers group insurance to members, for example.
If your skills are individually valuable, rather than being a commodity, consider working part time for either your previous employer or a random startup. There are other advantages to doing that as you set up on your own (peers to bounce ideas off, access to resources, actual income) but group health insurance is one of them.
Don't skimp on preventative care - dental and optical in particular. If you're young and healthy and don't have kids then you can skimp on the health coverage, going for a high deductible plan and doing the risk modeling yourself - a common thing for individual insurance, which can be very expensive otherwise. But if you have kids, or are thinking about it, don't do that.
And, once you've asked slashdot, talk to your spouse. Unless (s)he is on the same page about this, as well as everything else about setting up on your own, then you're well and truly fucked, both in relationship and business terms.
Windows 7 can still be targeted by a IE bug that's been in place since IE6. Safari doesn't have zero day bugs *that* old
How would you know? Zero-day means a non-public exploit.
Safari was released in early 2003.
Internet Explorer 6 was released in August 2001.
So the unfixed Internet Explorer bugs have been around quite a bit longer than Safari has. So Safari is unlikely have any bugs older than this IE bug, zero-day or otherwise.
(OK, there could be crusty KHTML era bugs left in the Safari code-base, but there's not much of that code left untouched)
I'll take Qt Creator over Visual Studio for C++ development any day.
If 9% of the list o' terrorists are also on the no-fly list, that means that the feds are happy with 91% of terrorists being on airplanes.
64 bit binaries consume more space than 32 bit binaries. That means they make less effective use of system memory and (just as importantly) CPU cache.
All other things being equal, a 64 bit binary will run slower, while using more system resources than a 32 bit binary, so it's something that you'd only want to do if you could actually make use of huge amounts of memory in your application directly.
All other things aren't equal, though, as x86 is rather a "special" architecture. There the 64 bit binary will get access to (amongst other things) more registers. It'll still consume more system resources (ram, disk, power), but may run faster, or slower.
So it's not as simple as "64 bit good, 32 bit bad".
But they've been mostly $0.99, up to maybe $2.99 and run on my iphone, rather than $50+ running on my PC.
Better than the $50 games, some of them, too.
Odd. I have much the same perspective as you, but with VHDL and Verilog reversed. I see Verilog as being slightly closer to hardware and VHDL as a little better matched to architectural modelling. I suspect it depends on the tools and workflow you get used to more than anything intrinsic to either language.
You can certainly make the "being a software developer" mistake in either language - I don't think that's a reason to choose one over the other, rather it's just something to be very aware of.
Your job is not to be an advocate, it's to support your users to the best of your ability. That means steering them towards stuff you know how to support, but doesn't mean pushing them towards your favorite hobby OS when that's not a good match for them.
The most important thing is to support what your users need to do. For creative users, including writers, that means the tool they're familiar with. If they're used to Windows and Windows tools, give them Windows. If they're used to OS X, give 'em a Mac. Either way, give them a usable screen and a good keyboard - writers will likely kill you if their main writing machine has a plasticky 93% size keyboard.
The second most important thing is to make sure that the systems are available and the data is safe. Which makes Windows a PITA to support if you're not familiar with Windows administration (which is what it sounds like).
If it were me, I'd use Macbook Pros running OS X, with VMWare Fusion with unity mode turned on allowing me to run Windows (or Linux, come to that) applications, as though they were native apps. (Don't skimp on RAM). That way the machines can be shared by users who prefer different apps to do what they do, and you can take advantage of either the OS X level stuff or the underlying unix to do backups.
And a couple of cheap netbooks for emergencies, email, throwing in the back of a truck, that sort of thing. Then a bunch of robust, cheap media for ad-hoc backups (USB sticks, CD-Rs).
But I'm not your users. Ask them what apps they need, then work out how best to support them.
Even a webmonkey does some backend work.
You can write insecure websites using pretty much any tools, but if you're using MySQL and PHP, especially if you're using other peoples code in your app, you're probably going to end up with a security nightmare, regardless of how hard you try.
It's possible to write secure code in PHP, but almost nobody does, and most of the PHP code that you can acquire easily is painfully insecure. A never ending race to patch a never ending series of holes means you've already failed at security. Depending on "white-hat hacking", ditto.
Other than that... security is something integrated process, starting with the architectural design, the implementation and the processes around it, documentation and maintenance. It's not something you can just add on the side.
Books? No idea, but looks for stuff that talks about the entire lifecycle, and that comes from real world experience.
Oh, and learn some real crypto, so you can avoid both the snake oil and the irrational paranoia.
Summarhy for timmarhy: x x x xx xx x x xx x x x x
You don't know what "marginal cost" means, do you?
It means the cost to create one extra item of something, once you're already making a bunch of them. In the case of software it's the distribution cost.
That tends to be extremely low for any software product (which is why we seldom get manuals in the box now, as they add a lot to the marginal cost) and is close to zero for online distribution. Even if you're paying through the nose for bandwidth your incremental cost for a CD size .iso is a few pennies. If you use something like bittorrent, to leach off your users bandwidth (I'm looking at you, Blizzard), your incremental cost is likely an order of magnitude or two less than that.
I don't disagree much with this, but I think it can be expressed much more concisely as "I'm old. I want games to be just like my rosy memories of games when I was young, maybe prettied up a bit."
If knowing PHP and MySQL are critical skills for your CIO, you have far, far bigger problems.
Midori is also the name of a well known expert on Japanese Rope Bondage (NSFW). It's possible that Microsoft know exactly what this OS will be like.
It's little known mostly because it's not actually true. I think you're confusing theplanet with the world, aka world.std.com.
That depends. One of the obvious ways to do this is simply to steal the boards that failed burn-in testing and resell them. Those boards will mostly work, except for when they don't. Symptoms for the end user could be random crashes, failing to work with some speeds of RAM or CPU or only running for 10 minutes before crashing.
... will probably not involve C++ development.
There are a few reasons for that. The minor ones are that most C++ / ObjC projects are big enough that it's difficult to bring an experience programmer in to work on them for just a few weeks, let alone someone with no large project experience. Not impossible, by any means, but not something that a larger company is likely to do outside of a more formal (and longer term) sponsorship arrangement.
The big reasons are that the absolute _last_ thing you need either on your resume, or to enhance your skill set is a brief job coding. The basic coding is something that you should be picking up the basics of in college, rounding out a little with some personal coding (helping out with the countless open source projects out there, for instance) and won't really bring to fruition until you're doing it full time.
The skills you're less likely to pick up there, but which you can pick up in a shorter temporary project are things like QA, marketing, sales, system administration, maybe even customer support. So look at picking up a grunt work job in the field that's not directly touching code. QA and testing (for a real software company, not EA or anything in that field) is a gig you might well be able to pick up, and which would teach you more about good software design and good software project management in a painful 8 weeks than you'd learn in a year writing software. If you can do that in an early-stage startup, and see that business process too, at least from the sidelines, even better.
Heck, if you could wangle it, working as a gopher for one of the Sand Hill Rd VC firms would be one of the best introductions to a career in the software field, I think.
The PDF is 326,093 bytes. The HTML is 184,296 bytes, and pulls in an additional 74,847 bytes in associated files, leading to a total download of 259,143 bytes. So, you're saving about 20% by going for the malformed, painful to read version. Time to read first page is probably comparable, if you're using a browser with adequate PDF support (which if your browser dates from the same era as your 14.4k modem, it probably doesn't).
Of course, with the HTML you also have the option of throwing away all the formating and reading it in lynx, saving yourself about 43% over the PDF.
Or you could just read the slashdot thread about it, and get the salient points in a mere 50k, plus images, flash ads and so on.
The content looks OK, but whatever app they used to convert from TeX to HTML not only produces ugly code that gives Frontpage a run for it's money, it also didn't close the <address> tag near the top, making the entire document right justified and italic.
Horribly broken HTML in a bunch of respects. Stick with the PDF version.
The article has this so wrong that it's not even funny.
DKIM has pretty much nothing to do with phishing, and will do absolutely nothing to make phishing more difficult (though you could build some sorts of phish defenses based on DKIM I wouldn't bet on them being very effective, and they're certainly not what DKIM was really designed for).
DKIM is designed to allow the sender of a piece of email to cheaply embed a cryptographic signature in the mail to prove that they sent the mail. It's not usually used at the end-user level, rather a consumer ISP might sign all the mail coming from their smarthost or a company sending a newsletter may sign that email using their domain, even though they're sending it out via their ISP or via an ESP.
That signature doesn't mean anything other than I take responsibility for this email.
That has two uses that are (mildly) related to spam or phishing. The first is that it means that when you get a piece of email and hit the "this is spam" button it's easy for your ISP to work out who to send the feedback report to.
The second is a bit more subtle. It allows a sender of email to attach a persistent identity to the mail they send, in a way that can't be spoofed by others and which is independent of the IP address the mail comes from. That allows receiving ISPs to accurately track the reputation of senders of email, tied to that DKIM identity. If, say, Cisco signs all their newsletters with DKIM, and I as an ISP haven't seen customers complain about that DKIM signed mail from Cisco then when this new email arrives Cisco I can be pretty sure that my customers won't complain about that, either. I can avoid some expensive content based spam filtering, deliver the mail directly to the inbox and avoid false positives.
Note that I don't give that mail that red carpet treatment because it is DKIM signed - I do so because the DKIM signature proves that it comes from a sender that I've decided to trust because of their good behaviour in the past. You can think of it as kind of like a cryptographically signed "From" address, if you like, or as an identity that receivers can use to track reputation that's more convenient to receivers and senders than peer IP address.
Why not S/MIME or PGP? Well, DKIM can be cheaper to sign and check than either, but the real reason is that DKIM doesn't change the body of the email at all - just adds a few headers - so it doesn't require any special changes to the recipients mail client to be readable, and doesn't leave ugly detritus in non-DKIM aware clients. (The tradeoff of that is that DKIM is slightly fragile - some forms of body modification in transit will break the signature - but that's OK, as DKIM isn't designed to work 100% of the time, and if the signature breaks the mail will just be treated on it's merits, without the benefit of additional history).
DKIM will be (and is) used by spammers, of course, but it won't buy them anything other than making it easier for ISPs to track their reputations. And, in the case of spammers, that's a bad reputation (so they'll likely cycle through lots of identities in DKIM, just as they do everywhere else, to leave that bad reputation behind them). But it only provides advantages to the sender of the mail if they use a consistent DKIM identity over the long term, and consistently send mail recipients don't object to.
dkim.org has all the technical info and suchlike on DKIM.
You can't release it without management buy-in. Your manager knows vastly better than you whether that could happen, and how to get it to happen.
If your manager agrees with you that open sourcing it might work, he'll know how to do so. If not, it's not happening anyway.
The OLPC also has a vastly smaller display (7.5" ?), small (256k) main memory and tiny (1 gig) permanent storage and, I think, a 15Wh batter (as compared to four times that in a typical laptop). Those are possibly decent engineering tradeoffs to ship a cheap system with adequate battery life, but in terms of usability they're pretty crappy compared to second-hand laptops from a couple of generations back.
There are some more links, including to the DoJ docs and some history here.