This is a great example of revisionist thinking. Pretty much the whole industry (computer and retailing) thought the Apple stores would fail, and fail tremendously. The only other computer retailer at the time was Gateway, and those stores crashed and burned a few months before Apple opened its first store.
The Apple store was in no way a sure thing, and anyone that believes that they were wasn't paying attention.
Well, you may be thinking about it incorrectly, which is why you're confused.
You want a document. Do you really care how it's stored, or what it's internal representation is? No...you just want the phosphors on your monitor to show the correct patterns when you look at it.
Why do you need separate address spaces? Separate address spaces are required for protection. But that protection is needed because of how programs are written today.
etc etc etc.
In any case, a file today is just a representation of an ordered set of bits. No different than anything else.
Way back in the day, nobody could even figure out how to do credit card processing, much less buy anything online. I have a vague recollection of one of the backbone providers in the Northeast or Midwest trying to prohibit commerical traffic over their network.
One-click buying was pretty radical. Even buying stuff online was pretty unbelievable. I mean, think about this: some company you never heard of would store your credit card number and other information so you could buy stuff without entering in all the supporting info. This was back in the day when the big debate was PPP vs SLIP, and you couldn't get a commercial PPP account (except via netcom, I think).
Now all this stuff is pretty obvious. Back in the day, just buying stuff online was pretty wild. One-click, from the engineering side, was really original. The fact that it sounds so quotidian shows how far things have come since then.
I would argue that the electoral college is designed that way because it's the states that elect the president, not the people. Remember, there was a real wariness about the federal government in general, probably more so than today. Nobody wanted the federal government to do anything exiting, like levy taxes on everyone.
Thus, the electoral college. The electors vote for the president, and those electors in turn are elected by the populace of the states. Those voters were essentially vetted by the states, since the electors were appointed by the current party structure(s)...and the voters, of course, had to pass certain criteria to vote.
It's yet another check. It hasn't really been used, but that doesn't mean it should be taken away.
If you see California and New York as a problem, then splitting the electoral vote of a state would be a solution. That would hurt the Democrats tremendously, so it won't happen; it would essentially marginalize all the cities.
The EC really works fine, for the most part. There's only been what, one issue in the last few hundred years, and that's hardly a reason to revise anything.
What does responsibility mean? Can you fire them and increase their salaries? If so, then they should be relatively motivated to at least meet your expectations.
What can you do to make it easier? Don't be a bozo. That means (1) take the political heat for your team, and (2) try and insulate them from changes in specs. Or, (3) make sure they know what they're building/supposed to do.
Think of them as normal employees, not programmers. Sure they may be smart, but they're still people. Possibly weird, potentially infantile, probably high maintenance, and hopefully productive people, but they're still people. So treat them like everyone else.
Oh, and be sure to treat them like experts. They like that.
I remember working on this for a bit. One reason it was a bit more difficult than normal to crack open is we replaced all the appropriate 68k exception vectors with RTEs, so you couldn't hop into Macsbug or do an NMI and disassemble anything.
Once multifinder came out that method died, because the exception vectors were on a per-process basis. You could just break into another app and dump the RAM.
I vaguely remember that it was a fun and interesting idea back in the day. Plus, it was william gibson, and his aura was much stronger back then.
I always thought that CS was more about theory, which means that a low level language should be the first. How low depends on the faculty, I suppose.
If you really want to understand what's happening, assembly and the various ABIs are really the only way to go. What are the downsides of various ways to implement C++? What are the tradeoffs between different CPU architectures? Why use a register vs a stack-based model? What kinds of problems are better modeled in certain languages than others?
Most of these questions can't be answered by learning Java. Heck, I doubt anyone these days even reads java bytecodes and notices how crappy the optimization is (hello, has anyone even heard of CSE?). Have you thought about how OO causes code bloat because you can't strip dead code?
If you care about the language, then you should be looking at why certain things are in the language. It doesn't really matter what the language is. Why doesn't Java do MI? What are the issues with MI vs mixins?
98% of computer work today is basically gluing libraries together. It's probably more like 99.999%, but I'm being kind. Most coding is bugfixing, or working around decisions made years ago by someone without enough time. That's not CS, that's plumbing.
First language to learn? It should be z80, 6502, or 68k. They're nice, expressive, and relatively simple. x86 should be next because it's so common, then RISC, either SPARC or PPC. Maybe a VLIW would be nice. Not sure the custom chips (cray, thinking machines) matter so much - include them if you have time. Then branch out into subsystems (the storage hierarchy), I/O, etc.
You mean rating a movie on the different metadata dimensions. That's tough, because that information may not exist. It's a data problem, not a math problem. That's probably why ebay asks all those extra questions now when you buy something.
If the Napoleon Dynamite movies are such outliers (like Buckaroo Banzai), they should just special-case them and move on. With a data set this big, there's no point in having a catch-all algorithm, especially if the outliers are such a big problem. Instead, the code should recognize the outlier and just flip a (virtual) coin as to the rating (or shunt it off somewhere else).
Well, that's the wrong question as well. Only in highly structured environments can you collect all the requirements. And in those highly structured environments (ie: government, military, public safety) how many software projects come out meeting the requirements, are on time, and on budget?
The answer is probably very small. In fact, I'd guess that the only things that a highly structured development process gets you over a fast, iterative and mostly loose process are (1) CYA material, (2) aggravation, and (3) consulting dollars. You get #2 with any development process, but at least in a structured process you aggravate everyone else as well.
In any piece of software there comes a time when what you built doesn't fit so well with what your customer is asking for anymore. Lucky for you it happened sooner rather than later.
All the people who talk about e-voting want a paper record. But that has its own problems, the main one being the same problem as any voting system:
How do you know if your vote is registered correctly or not?
With a secret ballot, there is no transparency. The only thing you can verify is that approximately the same number of people that went into the machine cast a vote. And at least in the US, there's no requirement that you actually cast a vote when you're in the booth, as far as I can tell. I've never tried to walk out without voting, but I expect there's no way they can force you to vote.
Are the tallies wrong? How can you tell, except by interrogating every voter...which wouldn't work, because voters may lie or change their vote when asked what/whom they voted for.
In fact, how many paper ballots are invalidated because the voter voted for multiple candidates or otherwise invalidated their ballot? 2% may be low compared to real paper ballots.
e-voting doesn't make fraud any more or less difficult. It just makes things less transparent, and probably makes fraud easier.
Instead of having to print and fill out tens of thousands of ballots, register lots of dead people, or stuff ballot boxes, all of which have severe logistical problems and can be traced with a bunch of work, all you need to do perform e-fraud voting is compromise a couple of computers up in the food chain. There is no reliable auditability for e-voting unless you remove the secret ballot requirement...and even then, it's all plastic anyway. Logs (and audit logs) are a lot easier to fake than tens or hundreds of thousands of paper ballots. The latter requires coordination among large numbers of people; e-voting fraud just requires a couple of focused and motivated geeks. Bits are bits, baby, and our jobs is to make sure the bits are in the right order.
i'd trust paper ballots over any kind of e-voting any day. It's not hard to design a ballot that doesn't allow hanging chads. It's probably impossible to design a computer system that can't be compromised by someone with enough motivation.
Well, middleware tends to have a bus publish/subscribe architecture. So you throw a whole lot of data onto the bus, and you don't really care where it goes. Clients are clients of the bus, and generally register for data that they're interested in.
The standard example for this kind of stuff is stock trading. Your stock app basically dumps all the transaction information onto the bus in realtime, and clients register for notification of trades on specific ticker symbols or some kind of criteria (>1000 shares, price), or any combination of things.
As long as the message contents are standardized, anyone can listen (or post)...assuming they have the correct permissions, etc.
This doesn't sound hard, until you realize that comes to around 10379 trades/sec given today's DJIA trading volume.
The bus architecture seems to have scaled up pretty well. I remember when trading volumes were a lot less. Note that the bus (solution) generally:
* requires transactions * requires guaranteed delivery * requires a guaranteed latency time * requires absolute uptime during its operational period * requires that data never be lost, ever
Lots of features fall out from those, such as distributed architecture, redundancy, failover, hot standby, replication, fault tolerance, etc.
Luckily, the realtime platform only needs to run during market hours (and some period before/after). So technically you only need about 6.5 hours of uptime per day (make it 10 hours for settlements, etc).
Why would you use a bus? Because it means you don't have to care how clients connect to you. Throw your message onto the bus, and that's all you need to worry about. You don't have to worry about transaction support, security, all that other crud. Your app's job is to connect to the bus and feed it data.
Likewise, the client just needs to hop onto the bus and register for the messages that it cares about (and presumably understands). You'd think you'd lose performance because it's so decoupled, but you don't.
Actually, this happened at my old company occasionally. There were ways around rebuild errors, all of which were manual. In a few cases I remember the content wasn't recoverable, and they had to transfer all the content from another site.
All you need is a bad batch of drives, and your whole infrastructure is hosed.
Actually, the wikipedia entry is wrong. They Honeywell patent is:
Title: Multiple independently positionable recording-reading head disk system
Abstract ------ A multiple independently positionable recording-reading head optical disk system. The system includes at least one optical disk having an arrangement of data elements. A plurality of recording-reading heads read and write data onto the optical disk. An apparatus for transporting the plurality of recording-reading heads over one side of the optical disk enabling each of the recording-reading heads to read data from or write data onto the optical disk independently of the other recording-reading heads.
--
This is not a TiVo. This is how to record onto optical media with multiple independent read/write heads.
This demonstrates why you should actually verify information in WikiPedia instead of quoting it blindly.
The device relies on the assumption that the physiology of people up to no good may be different than normal people.
And that may be true.
However, this'll be much more useful somewhere like an embassy or checkpoint than in an airport. In a sea of potentially hostile people, it's harder to pick out the ones who may actually do something. In a sea of basically docile people, it should be relatively simple to visually pick the nervous ones.
Well, the main problem with distributing via Bittorrent is that if you're the only one seeding nobody will be able to get to 100% (and thus be able to watch your flick) for a while. Sort of obviates the benefit of bittorrent. Bittorrent's main assumption is that 100% of your content is available at any given time, and for best results it should be available from more than one host.
Witness the 1 seed/255 leech phenomenon. If that 1 seed is on a normal home connection (with 41k up), bittorrent distribution of that film will take a while.
Plus, you'll saturate your upstream connection, which means your internet connection will be pretty useless.
Stick it on YouTube. They have a high-quality format option which should be good enough.
In addition, there are a ridiculous number of people that live in crushed-in squalor today. They'd trade their current sqalor for a nicer squalor anytime.
Slashdot Mirror
The founder of this non-profit is a genius!
1. create non-profit with catchy name
2. issue press releases
3. complain to government agencies
4. blackmail large companies for donations
5. profit!
Those extra two steps separate it from the pack.
A shop owner said that the vendor told us that they cracked the code.
Now...WTF does the shop owner know?
Would he sell them if the vendor told him "we buy them using stolen credit cards and sell them to you?"
Evita sang it best (Patti LuPone, not Madonna):
I was stuck at the right place at the perfect time
Filled a gap - I was lucky, but one thing I'll say for me
Noone else can fill it like I can
This is a great example of revisionist thinking. Pretty much the whole industry (computer and retailing) thought the Apple stores would fail, and fail tremendously. The only other computer retailer at the time was Gateway, and those stores crashed and burned a few months before Apple opened its first store.
The Apple store was in no way a sure thing, and anyone that believes that they were wasn't paying attention.
Well, you may be thinking about it incorrectly, which is why you're confused.
You want a document. Do you really care how it's stored, or what it's internal representation is? No...you just want the phosphors on your monitor to show the correct patterns when you look at it.
Why do you need separate address spaces? Separate address spaces are required for protection. But that protection is needed because of how programs are written today.
etc etc etc.
In any case, a file today is just a representation of an ordered set of bits. No different than anything else.
The reason NASA isn't a military project is simple: the aliens wanted it that way.
Way back in the day, nobody could even figure out how to do credit card processing, much less buy anything online. I have a vague recollection of one of the backbone providers in the Northeast or Midwest trying to prohibit commerical traffic over their network.
One-click buying was pretty radical. Even buying stuff online was pretty unbelievable. I mean, think about this: some company you never heard of would store your credit card number and other information so you could buy stuff without entering in all the supporting info. This was back in the day when the big debate was PPP vs SLIP, and you couldn't get a commercial PPP account (except via netcom, I think).
Now all this stuff is pretty obvious. Back in the day, just buying stuff online was pretty wild. One-click, from the engineering side, was really original. The fact that it sounds so quotidian shows how far things have come since then.
>
I would argue that the electoral college is designed that way because it's the states that elect the president, not the people. Remember, there was a real wariness about the federal government in general, probably more so than today. Nobody wanted the federal government to do anything exiting, like levy taxes on everyone.
Thus, the electoral college. The electors vote for the president, and those electors in turn are elected by the populace of the states. Those voters were essentially vetted by the states, since the electors were appointed by the current party structure(s)...and the voters, of course, had to pass certain criteria to vote.
It's yet another check. It hasn't really been used, but that doesn't mean it should be taken away.
If you see California and New York as a problem, then splitting the electoral vote of a state would be a solution. That would hurt the Democrats tremendously, so it won't happen; it would essentially marginalize all the cities.
The EC really works fine, for the most part. There's only been what, one issue in the last few hundred years, and that's hardly a reason to revise anything.
What does responsibility mean? Can you fire them and increase their salaries? If so, then they should be relatively motivated to at least meet your expectations.
What can you do to make it easier? Don't be a bozo. That means (1) take the political heat for your team, and (2) try and insulate them from changes in specs. Or, (3) make sure they know what they're building/supposed to do.
Think of them as normal employees, not programmers. Sure they may be smart, but they're still people. Possibly weird, potentially infantile, probably high maintenance, and hopefully productive people, but they're still people. So treat them like everyone else.
Oh, and be sure to treat them like experts. They like that.
I remember working on this for a bit. One reason it was a bit more difficult than normal to crack open is we replaced all the appropriate 68k exception vectors with RTEs, so you couldn't hop into Macsbug or do an NMI and disassemble anything.
Once multifinder came out that method died, because the exception vectors were on a per-process basis. You could just break into another app and dump the RAM.
I vaguely remember that it was a fun and interesting idea back in the day. Plus, it was william gibson, and his aura was much stronger back then.
I always thought that CS was more about theory, which means that a low level language should be the first. How low depends on the faculty, I suppose.
If you really want to understand what's happening, assembly and the various ABIs are really the only way to go. What are the downsides of various ways to implement C++? What are the tradeoffs between different CPU architectures? Why use a register vs a stack-based model? What kinds of problems are better modeled in certain languages than others?
Most of these questions can't be answered by learning Java. Heck, I doubt anyone these days even reads java bytecodes and notices how crappy the optimization is (hello, has anyone even heard of CSE?). Have you thought about how OO causes code bloat because you can't strip dead code?
If you care about the language, then you should be looking at why certain things are in the language. It doesn't really matter what the language is. Why doesn't Java do MI? What are the issues with MI vs mixins?
98% of computer work today is basically gluing libraries together. It's probably more like 99.999%, but I'm being kind. Most coding is bugfixing, or working around decisions made years ago by someone without enough time. That's not CS, that's plumbing.
First language to learn? It should be z80, 6502, or 68k. They're nice, expressive, and relatively simple. x86 should be next because it's so common, then RISC, either SPARC or PPC. Maybe a VLIW would be nice. Not sure the custom chips (cray, thinking machines) matter so much - include them if you have time. Then branch out into subsystems (the storage hierarchy), I/O, etc.
With a porcupine, the pricks are on the outside! // old joke // had 3 bimmers, miss them all
You mean rating a movie on the different metadata dimensions. That's tough, because that information may not exist. It's a data problem, not a math problem. That's probably why ebay asks all those extra questions now when you buy something.
If the Napoleon Dynamite movies are such outliers (like Buckaroo Banzai), they should just special-case them and move on. With a data set this big, there's no point in having a catch-all algorithm, especially if the outliers are such a big problem. Instead, the code should recognize the outlier and just flip a (virtual) coin as to the rating (or shunt it off somewhere else).
Wow, I did not know that existed. This is probably the first time I've learned something from a /. article in months.
Thanks!
Well, that's the wrong question as well. Only in highly structured environments can you collect all the requirements. And in those highly structured environments (ie: government, military, public safety) how many software projects come out meeting the requirements, are on time, and on budget?
The answer is probably very small. In fact, I'd guess that the only things that a highly structured development process gets you over a fast, iterative and mostly loose process are (1) CYA material, (2) aggravation, and (3) consulting dollars. You get #2 with any development process, but at least in a structured process you aggravate everyone else as well.
In any piece of software there comes a time when what you built doesn't fit so well with what your customer is asking for anymore. Lucky for you it happened sooner rather than later.
All the people who talk about e-voting want a paper record. But that has its own problems, the main one being the same problem as any voting system:
How do you know if your vote is registered correctly or not?
With a secret ballot, there is no transparency. The only thing you can verify is that approximately the same number of people that went into the machine cast a vote. And at least in the US, there's no requirement that you actually cast a vote when you're in the booth, as far as I can tell. I've never tried to walk out without voting, but I expect there's no way they can force you to vote.
Are the tallies wrong? How can you tell, except by interrogating every voter...which wouldn't work, because voters may lie or change their vote when asked what/whom they voted for.
In fact, how many paper ballots are invalidated because the voter voted for multiple candidates or otherwise invalidated their ballot? 2% may be low compared to real paper ballots.
e-voting doesn't make fraud any more or less difficult. It just makes things less transparent, and probably makes fraud easier.
Instead of having to print and fill out tens of thousands of ballots, register lots of dead people, or stuff ballot boxes, all of which have severe logistical problems and can be traced with a bunch of work, all you need to do perform e-fraud voting is compromise a couple of computers up in the food chain. There is no reliable auditability for e-voting unless you remove the secret ballot requirement...and even then, it's all plastic anyway. Logs (and audit logs) are a lot easier to fake than tens or hundreds of thousands of paper ballots. The latter requires coordination among large numbers of people; e-voting fraud just requires a couple of focused and motivated geeks. Bits are bits, baby, and our jobs is to make sure the bits are in the right order.
i'd trust paper ballots over any kind of e-voting any day. It's not hard to design a ballot that doesn't allow hanging chads. It's probably impossible to design a computer system that can't be compromised by someone with enough motivation.
Well, middleware tends to have a bus publish/subscribe architecture. So you throw a whole lot of data onto the bus, and you don't really care where it goes. Clients are clients of the bus, and generally register for data that they're interested in.
The standard example for this kind of stuff is stock trading. Your stock app basically dumps all the transaction information onto the bus in realtime, and clients register for notification of trades on specific ticker symbols or some kind of criteria (>1000 shares, price), or any combination of things.
As long as the message contents are standardized, anyone can listen (or post)...assuming they have the correct permissions, etc.
This doesn't sound hard, until you realize that comes to around 10379 trades/sec given today's DJIA trading volume.
The bus architecture seems to have scaled up pretty well. I remember when trading volumes were a lot less. Note that the bus (solution) generally:
* requires transactions
* requires guaranteed delivery
* requires a guaranteed latency time
* requires absolute uptime during its operational period
* requires that data never be lost, ever
Lots of features fall out from those, such as distributed architecture, redundancy, failover, hot standby, replication, fault tolerance, etc.
Luckily, the realtime platform only needs to run during market hours (and some period before/after). So technically you only need about 6.5 hours of uptime per day (make it 10 hours for settlements, etc).
Why would you use a bus? Because it means you don't have to care how clients connect to you. Throw your message onto the bus, and that's all you need to worry about. You don't have to worry about transaction support, security, all that other crud. Your app's job is to connect to the bus and feed it data.
Likewise, the client just needs to hop onto the bus and register for the messages that it cares about (and presumably understands). You'd think you'd lose performance because it's so decoupled, but you don't.
Actually, this happened at my old company occasionally. There were ways around rebuild errors, all of which were manual. In a few cases I remember the content wasn't recoverable, and they had to transfer all the content from another site.
All you need is a bad batch of drives, and your whole infrastructure is hosed.
Actually, you're wrong.
Simple examples:
We ship version 1.0
We ship version 1.1
We ship version 1.2
A customer wants a fix to 1.1 and doesn't want to upgrade to 1.2. That fix should also be moved forward to 1.2.
We want to try something in 1.3, but we don't want to mess with everyone else's build.
Actually, the wikipedia entry is wrong. They Honeywell patent is:
Title: Multiple independently positionable recording-reading head disk system
Abstract
------
A multiple independently positionable recording-reading head optical disk system. The system includes at least one optical disk having an arrangement of data elements. A plurality of recording-reading heads read and write data onto the optical disk. An apparatus for transporting the plurality of recording-reading heads over one side of the optical disk enabling each of the recording-reading heads to read data from or write data onto the optical disk independently of the other recording-reading heads.
--
This is not a TiVo. This is how to record onto optical media with multiple independent read/write heads.
This demonstrates why you should actually verify information in WikiPedia instead of quoting it blindly.
The device relies on the assumption that the physiology of people up to no good may be different than normal people.
And that may be true.
However, this'll be much more useful somewhere like an embassy or checkpoint than in an airport. In a sea of potentially hostile people, it's harder to pick out the ones who may actually do something. In a sea of basically docile people, it should be relatively simple to visually pick the nervous ones.
People are not Personal Computers. People use personal computers.
Have these people subsumed into the MS-Borg, and they really are now PCs?
Well, the main problem with distributing via Bittorrent is that if you're the only one seeding nobody will be able to get to 100% (and thus be able to watch your flick) for a while. Sort of obviates the benefit of bittorrent. Bittorrent's main assumption is that 100% of your content is available at any given time, and for best results it should be available from more than one host.
Witness the 1 seed/255 leech phenomenon. If that 1 seed is on a normal home connection (with 41k up), bittorrent distribution of that film will take a while.
Plus, you'll saturate your upstream connection, which means your internet connection will be pretty useless.
Stick it on YouTube. They have a high-quality format option which should be good enough.
When you're associated with success, the press just calls you for things..just like sci-fi actors and actresses. Plus, he interviews well.
In addition, there are a ridiculous number of people that live in crushed-in squalor today. They'd trade their current sqalor for a nicer squalor anytime.