If I had any moderator points, you'd get them. I think this comment is more insightful than it appears at first glance. While I applaud the articles root authors desire to help an open source project, it is a slightly different way of approaching the problem. Maybe the best way the root author can help open source projects is to "meta-help" them- make it easier for open source projects that need help in areas that are beyond their skill sets to connect with people willing to provide that help. For example, in my open source project, I've got the programming, HTML, and documentation needs pretty much covered. However, I do need help with the following:
o Art. I can't draw stick figures. But I do need a few pieces of art such as an "Icon" in various forms and resolutions. Possibly a few "icons", such as a "represents the whole project", and an icon for different sub-projects (i.e., something like Mozilla -> Firebird, Thunderbird).
o Translation. It would be nice to do some internationalization. There's actually a few levels to this, as well. There's some relatively simple tasks, such as localizing approximately two dozen run time error messages, all the way up to a major undertaking like localization of the documentation.
There's obviously a few more high level categories that apply to most projects as well (porting, testing on platforms not readily available to the developers, etc).
So, maybe some kind of "open source job site" where project owners can post "jobs" and include details like the type of license that is required for any contributions.
Display coalescing was introduced way back in 10.4. This was well documented, and as the Firefox developer points out, there's even tools provided to enable and disable this behavior to see if you're being limited by it.
While I don't know all the details, I would venture to say that far from Apple "Secretly Crippling Non-Apple Software" (which they conveniently provide release notes and debug tools with the stock Xcode tools for this secret behavior), this has exposed a serious performance problem in Firefox.
To put it another way, display coalescing will effectively penalize apps that are rendering more updates that are physically possible to display. As an extreme example, this roughly equivalent to rendering / writing 60 frames of video to the display in 1/60th of a second, which can only possibly display one of those 60 frames. The rest are just wasting CPU, GPU, and bandwidth resources which could be better spent doing other things. Display coalescing will cause an application to "stall" if it's forcing too many updates, the call to flush the buffer just won't return until the the current frame has fully rendered.
Mac OS X prior to 10.4 did not enforce this, and so as one of those compatibility trade-offs, display coalescing is turned off by default when certain conditions are detected. I believe anything linked prior to 10.4 will trigger it, and carbon apps. Carbon is essentially for those who are unwilling to (almost literally) join the 21st century.
Just how secret can it possibly be with publicly available release notes published years ago?
Just in case anyone is wondering, the parent is flat out wrong.
The case for the Itanium is that the reason it failed in the Wintel world
Wrong. The Itainium never competed in the Wintel world. It was designed to captalize on the high margin server chip business (Alpha, HPPA, Sparc, etc). It failed in that market because frankly, it sucked. Tragically, this ended up killing the Alpha CPU due to the DEC/Compaq/HP shinanigans. The alpha was the speed king, and even though there's been virtually no work done on them since 2000, they're STILL some what competitive.
was the difficulty of programming for it, notably its ramant use of out of order instruction capability.
Wrong. Programming for it is like any other chip- you use a compiler. Now, writing compiler back ends for it is very difficult because it's a VLIW design, meaning each 'instruction' is actually a bundle of multiple instructions, one for each exposed unit (I think there's 2 integer, 2 fp, and 1 branch per bundle).
This also makes your other point very, very wrong- the compiler is responsible for extracting the instruction level parallelism from the code stream, not the CPU with such tricks such as out of order execution.
Going Itanium could let them leapfrog the x86 world and have more headroom for growth.
Have you actually looked at the spec scores? The only thing the Itanium is better at is floating point, and not exactly by a killer margin, either. Opterons trounce it in integer performance, and are competitive in FP. And once you factor in price/performance, forget about it.
Surely intel has some response to the Cell. Are they going to cede the entire video game/ digital hub market to xbox, sony and the cell?
What, exactly, are they going to do? Design some killer chip combo and then ask pretty please, with suger on it, would you ditch your current xbox/ps3 design and switch to our stuff right now? Are they going to cede the entire video game / digital hub market to xbox and sony? It already happened, nothing to be done about it but maybe hope for a spot in five years.
To engage in pure speculation: A possible situation could be that the fire was started by one of his kids. They would've had access to his card (and typically, kids don't have much cash either).
To further this line of thinking, I would guess there's an even more likely possibility: The husband did actually buy the fire starting items in question and brought them home. Once home, the kids had ready access to them.
Also, it wouldn't surprise me if there were a law or regulation preventing the disclousure of a minors identity in such a situation. Or, assuming it is one of the kids, perhaps age and the facts of the matter played a part in the decision to not release their name. This could make a lot of sense under the right circumstances. How accountable is an eight or nine year old to such actions? And then to (potentially) have this show up during background searches when applying for jobs. While some jursidictions may allow for a minors record to be expunged, news paper clippings aren't quite as easy.
Further more, if the above is roughly true, the husband probably willing gave his safeway club card over and allowed them to obtain whatever records they wanted. Considering this, the husband might not have even realized the potential connection between the items bought and the physical evidence. Ironically, assuming it was one of the kids, this may have helped ferret out the real instigator because there was some strong circumstantial evidence that the required items were in the house.
It makes little sense from a business perspective as well; it costs up to ten times as much to fix an error by the time it hits the market as it would to catch it during the design.
Wow. You're right. Bugs are expensive any way you measure them. Since you're the team lead and sr. programmer, I'd like you to stop putting bugs in our products code. And since you're going to be writing less code (total code = useful code + bugs), you should be able to get the product done much earlier. HR will be having a chat with you about your compensation, what with doing less work and all that extra expense you've been causing us all this time.
Dumbass.
Let me grab a chair while we wait for your next enlightenment. Next thing you know you'll move the release date up six weeks because that would give us six more weeks of profit.
Some of the best advice I ever got was understand the difference between activity and acomplishment and avoid people who don't.
What problem does this fix?
on
Replacing TCP?
·
· Score: 2, Insightful
Up front, I believe that their product/solution/answer to the "TCP Problem" is specious, at best.
First order of business is "What is the problem?" This is never really adequately defined, near as I can tell. Some vague references to some "problems" with TCP without any objective data to support the statements. Since a solution is being proposed to a problem, we need some way to measure the problem objectively. How else can you tell if your proposed fix is better or worse than the baseline? Since the problem is never defined in any detail, and certainly never to a point of which you can measure, and the fact that there is no objective data, makes the whole thing totally suspect right from the start. In a nutshell, extraordinariy claims without extraordinary proof
Regardless, there are some nuggets here and there that we can pick apart (from the website):
#1 Rateless Internet is an Internet transport protocol implemented over UDP, meant as a better replacement of TCP. TCP's legacy design carries a number of inefficiencies, the most prominent of which is its inability to utilize most modern links' bandwidth.
#2 This problem stems from the fact that TCP calculates the congestion of the channel based on its round-trip time. The round-trim time, however, reflects not only the congestion level, but also the physical length of the connection. This is precisely why TCP is inherently unable to reach optimal speeds on long high-bandwidth connections.
#3 A secondary, but just as impairing, property of TCP is its inability to tolerate even small amounts (1% - 3%) of packet loss. This additionally forces TCP to work at safe and relatively low transmission speeds with under 1% loss rates. Nevertheless, our extended real-life measurements show that highest throughput is generally achieved at speeds with anywhere between 3% and 5% loss.
Point #1 is a claim without any evidence to back it up. Now most of us may think there is a hint of truth to this from experience. The danger lies in making an assumption that the problem is TCP. It could be a bad implementation of the stack you're using, some kind of packet loss in the path, or you're just trying to send too much data given the conditions of the test (ie, a Pentium 90MHz trying to fill a 10Gb/sec pipe). There's just too many variables that influence the amount of link utilization to make such a generalized statement that "TCP is inherently unable to reach optimal speeds on long high-bandwidth connections". There was a time when two Sun machines sitting next to each other couldn't utilize the entire capacity of a half duplex ethernet, for example. Yet it's not uncommon to have more bandwidth to your home via cable/dsl and make full use of it even on cross country/inter continental links these days without a whole lot of change to the fundamentals of TCP. Therefore, it's unreasonable to conclude that TCP is the cause of any of the problems, perceived or real, considering the history of TCP and it's scaleability over time and total lack of any effort to rule out other causes.
Point #2 is a case of where a little bit of knowledge is much more deadly than none at all. I'd be willing to chalk this one up to a marketing person's copy than any particular design insight by the developers, but it's spooky that it's there. At a fundamental level, queueing theory tells us that the average time for a unit to be processed in a queue is related to the depth of the queue. If there's nothing, or effectively nothing, in the queue when your packet arrives, there is no delay in sending the packet. However, the delay grows as the depth of the queue grows. This shows up as variability in the round trip times of packets, relative to each other. Also known as "jitter". Therefore, no jitter means there are no queueing delays, which means that there isn't much traffic competing for access to the links. High jitter means there are a lot of packets competing for access to a link, and therefore much more likely to be c
Another positive outcome of IPv6 will be better internet routing using QoS, Quality of Service, which routes packets based on priority.
What? There is nothing in IPv6 about this. You can do this right now, today, with IPv4 by having a flexible queueing methodology and flexible packet pattern matching systems. Violla. Any packet destined to network 1.2.0.0/16 that is TCP and port 80 no gets dumped in the high priority queue.
QoS is also the perfect snake oil. In a practical sense, QoS only "kicks in" when there's contention, when there's more data that needs to squeeze in to the pipe than can fit. QoS makes the choice of which packet gets to go over all the other packets waiting to go.
In other words, the only time QoS is of any good is when you are on a over subscribed, saturated network, where there isn't enough bandwidth available to meet demand. In simple terms, the network is broken, and QoS just helps pick who gets screwed the least.
Lastly, routing will be simplified because the IPv6 information header on each packet is far more flexible and can contain more detailed information than an IPv4 header thus allowing for faster routing of data across a network or the internet. Currently, most routers need to maintain as many as 48,000 different routes in their routing tables just to effectively route data that passes through them. IPv6 reduces this number by at least 75%.
This, too, is just flat out wrong. The only way this works is if you have a "clean slate" and parcel out IP addresses in a country/provider hierarchal fashion. Want to move providers? You get new IP's, out of their block. Want to multi home? Well, that kinda blows the efficiency right out of the water because now your network is no longer contained within the providers supernet, you have to announce your individual network both via your provider and where ever else you're peered. Therefore, you just added networks to the global routing tables.
Now, quick show of hands... how many of you want to run your systems off a single homed, single provider only network? And please, none of this god awful "let the router pick which source IP to use!" crap.
Also, if you're worried about IPv6 requiring you to change all of your software, learn new protocols, new methods of connecting, new ways of sending and receiving data or anything like that, fear not. The only thing really changing with IPv6 over what was in IPv4 is that you now have a larger address space which allows for more network addressable IP addresses, a more flexible header and packet system, and faster routing.
Yea, you don't have to change a thing. Not any of your software, or nothin'. Of course, you do need a whole new IP stack to talk IPv6, but that's pretty minor right? Windows folks can make this change by simply cracking open their registries and changing the IP Version key from 4 to 6. Ta da!
Faster routing? How's that? Does it make sense to anyone that looking up a 128 bit address is going to be faster than looking up a 32 bit address? There's more to look up.
Furthermore, all routers worth their salt use hardware accelerated forwarding engines these days. Modern BiCAM's or (nearly always) TCAM's can do single cycle lookup of an address out of a potential 512K entries. It doesn't matter how many entries there are, it can always do find the correct match in a single cycle. And 512K entries is a bit more than a default free routing table (~140K entries) that's common today, so there's no worries there.
The catch is, most of these hardware lookup engines are hard wired for IPv4, and can't easily be extended to IPv6, which means the packets become exception packets and need to be dealt with by the CPU. The CPU lookups are orders of magnitude slower than the hardware lookups. This means that performance for IPv6 goes right through the floor for most routers. Newer routers/blades are starting to come with IPv6 hardware accelerated, but there's an awful lot of infrastructure out there that has no IPv6 hardware acceleration.
Therefore, for most people, IPv6 will initially result in a signfigicant performance drop in terms of packets per second over IPv4.
In our quantum universe, the uncertainty principle makes it impossible even in principle to measure starting state to the required precision, for the schemes that are used for true random number generation in electronic systems. Additionally, if quantum processes are accepted as truly random, they inject enough noise to taint macroscopic events with true randomness if the consequences of the noise are given enough time to propagate.
In summary, true randomness exists as a very fundamental result of the laws of nature, and won't go away no matter how good our measurements get.
Well, let's be clear here. Our best models (ie, quantum mechanics) have a statistical nature at their core. They are quite capable of predicting a large body of phenomena. Not all observed phenomena, and there's a few odd points here and there, but it's pretty damn good.
This does not, however, mean that this is the way the universe works. It's just a mathematical model. Newton's models gave us VERY good results, but it ended up folding. Not quite folding, but being superceded by something that was a bit more accurate.
So, given this, the "uncertainty principle" is the best we have. It's also somewhat axiomatic. It just is. But why? What gives rise to it at a very fundamental level?
So, it works for now, but that doesn't mean that's the way things are. Who knows? Maybe at a fundamental level, at plank scale and time, it just looks like that because we are fundamentally incapable of making such tiny, minute measurements that the whole thing is really just a big pinball machine that changes depending on the initial conditions. It may seem the same to you and I, that atom right there letting go of that photon... but it may be at the plank scale the difference of between say, earth and mars.
Actually, 8 sockets would be correct. There's three flavors of opteron: single cpu (1XX), dual cpu (2XX), and eight cpu (8XX).
Of course, nearly all the motherboards you can buy today only use four of the eight way SMP capability. The slashdot title is a bit misleading, they're only demoing a 4 socket / 8 core version today but an 8 socket system is doable right now, today, with the 8XX series CPU's.
As the article says:
So what today might be an eight-way server will potentially become, mid-2005, an "eight socket" server with 16 processing cores.
Then the US Government should look for TERRORISTS, not WEAPONS. But, alas, doing so would require likely profiles of terrorists, and GOD FORBID we look closer at people whose background makes it more likely they are terrorists. . ..
Actually, this isn't possible. As a matter of fact, you make things considerably more insecure by doing just that.
Say a group of people fit this "profile". Now, things being the way they are in the world, it only catches 80% of them. So, if any one of them were to pick up a bomb and do the dirty deed, well, it's unlikely they'll make it.
Here's where the problem begins. It's pretty obvious if you've been "tagged" by the system. So, why not send your merry little band of enthusiasts through the system a few times? Explicitly not doing anything illegal.
Guess what? Those who are tagged by the system don't get to go on the big outting. Those who remain are pretty much free and clear.
The other problem is.... that profile is picking out people for a reason. Simply find a way to be "something else."
As an example... the profile says that most/all of the terrorists are men. Suzy, with her new baby, would never be a terrorist. Get the picture?
So, basically, these types of systems are fundamentally useless against trying to detect what it is you're looking for. It's trivial to circumvent it with a determined group.
Then there's the problems. Guess what, you get an awful lot of "false positives" from the system. And most people aren't terrorists (19 out of six billion, remember). Once you're in the system, what's the incentive to get you out? You think a screw up at the DMV is bad, well, my lubed up, latex covered fingers are going to make you wish for a hot and muggy, no air conditioning, babies crying everywhere, no line moving DMV.
Oh... and not just this time, EVERY TIME. Good luck convincing people you're "not a terrorist". As a practical joke, we'll put Timmy on the list. Oh, won't he have fun on his flight to Chicago, that'll be a riot.
So what exatly is the email address for "The American People?"
As every God fearing, christian, patriotic, white, American (God bless her), middle aged male knows it's FOXaroundtheworld@foxnews.com at the Fair And Balanced (tm) news reporting agency of Fox News
Possibly. But since you seem to acknowledge that a given population has a contrary view point, do they have a valid reason?
but I have no problem with the FBI being able to monitor conversation between criminals.
Sure. I'd venture that on a pure principle level, most people don't.
The problems usually begin with what "criminal" means. The ones who write the law have a pretty good idea of how they want the law to be used, and at the start everyone thinks it's a super idea. "Criminal" is written pretty broadly, trying to cover "the bad guys".
As the cliche goes, if you're not a criminal, you have nothing to worry about. If you're paranoid, I'd guess you shut up anytime a cop comes within hearing distance.
Later on, however, the enforcers would really like to make use of this provision because it's pretty potent. So the definition of "the bad guys" shifts a little through any number of legitimate means, such as changing the scope of what a criminal is to adding new crimes that fall under the original scope.
Then, a set of events takes place and all of the sudden it's really bad to be a "terrorist". And a terrorist is sort of loosely defined, but definitely someone who is against "the state" and what it represents, using any and all means at their disposal, including disinformation and propaganda.
Do we have a right to privacy? Sure. Do we have a right to keep criminal conversations private? No. Is this subject to abuse? Sure. Will we be abused by criminals who conspire in private? Of course.
What's a "criminal conversation"? Because history assures us with countless examples that those who make the decision on what a "criminal conversation" is rarely do it with YOUR best interests in mind.
Is discussing with other like minded individuals your displeasure with the current George W. Bush administration and planning activities to educate the public on the facts and what they can do to kick him out of office a "criminal conversation"?
Want an example? The PATRIOT act, which did away with such minor things like habeous corpus (considered by many to be the cornerstone of our justice system and made no one above the law, one of the fundamental checks and balances) and passed to deal with "extraordinary threat" in these "extraordinary times"..... being used for a copyright case. Legislation that bypasses most of the fundamental US Constitutional rights would NEVER be applied to anything frivolous.
Given the choice between giving criminals the freedom to conspire in private or the ability of the FBI to wiretap criminals, I've no problem opting for the former.
This is the beauty of the whole thing right here. Trivial means in the form of encryption exist that totally negate any benefit law enforcement would gain from such legislation. Most likely, these days, all the necessary tools exist on your computer right now (openssl).
The only people that this would be of assistance against are... well, idiots. Since you know you're going to be discussing things of particular interest to law enforcement, and they have the means to intercept it, it's in your interest to encrypt your communications. So, from a practical sense, the only information you're going to get out of this is that two people spoke to each other which is useless in court.
So... now what? We now have a system in place that's capable of catching none but the most utterly incompetent criminals and can be abused by the government against law abiding citizens.
I know! Let's outlaw encryption. That'll learn 'em.
In any case, the net is a public place. Nothing there is private.
This seems to be particularly specious reasoning. By the same token I can say that the entire planet is a public place, ther
When one is a salary man, a bit more is expected, within reason (which is the key).
Now, mind you, this varies from state to state, country to country, but in the US there are certain labor laws against this type of abuse.
First and foremost you have to understand what these two terms mean:
Salaried
Exempt
An exempt employee is always salaried.
A salaried employee is not necessarily exempt.
There is a difference. A huge difference. And I'd bet nearly all of you didn't understand the nuance. Guess which one your HR department has you marked down as, and I bet you never throught to even challenge it.
Exempt applies to a certain class of workers. IANAL, but roughly this means that you are (ta da!) exempt from certain labor regulations, such as number of hours worked and whether or not you get any over time. Exempt employees are, by definition, salaried. Believe it or not, most of the tech jobs don't fall under the "professional" exemption. This varies from state to state, states being able to offer stricter regulations than the federal mandates. California tends to favor the employee, not the employer. As a rule of thumb for this group, you can be exempt if you're an executive or have an advanced degree and the degree is required to work in your profession (ie, doctors, etc)
Salaried means you get a fixed pay rate per week. If you show up for 20 minutes a day, or even one day, you are required to get your full weeks salary. You can not be docked for hours missed unless it's for a full day, and there's limits on that too.
Of particular interest is the case of the salaried employee who is non-exempt. A non-exempt, salaried employee can work less than 40 hours a week but still must be paid for 40 hours. However, working more than 40 hours (or by your states laws) you are required, by law, to be paid for working those hours.
I'll bet you haven't been, huh? Keep track of those extra hours, and let your boss know. Should you be discharged, ask for your back pay. If they chuckle at you, contact your local department of labor and say you have an unpaid overtime claim. You're likely legally entitled to it, and the department will investigate and make a determination.
You can also be exempt and loose your exempt status unless the company is mindful of the laws. Are you exempt and you've been asked to take partial days off for vacation or sickness? In your companies eagerness to save itself $100, they likely lost your exempt status and opened themselves up to oweing you tens of thousands of dollars in back pay in overtime.
Now, as for the original question... that's kind of interesting. If you're in California, they may be liable for paying you while you at home. Possibly 24 hours a day.
IMHO, companies that are that f'ing cheap deserve exactly what they get.
Aren't their routers basically embedded *nix boxes?
No. IOS isn't based on any operating system. IOS has very little in the way of modern opperating system services. As a matter of fact, it's a cooperative multitasking system- any one process can lock up the system or stamp on the memory of any other process.
It's because of it's historical roots- these types of embedded systems were easier to write (at the start) and faster (less overhead, faster context switches). Today, I think it's a huge liability.
Forgive my ignorance, but if the code is truly solid code, without buffer overruns and the like, shouldnt this theoretically not matter
Yes, provided it's solid code. So the obvious question is: is it solid code? What makes for solid code? I'm of the opinion that it is far from 'solid' code for two main reasons.
The history of the code base.
It's monolithic nature.
IOS started out on the same CPU board as Sun (and SGI) computers: The Stanford 68000 board. Remember what Sun stands for: Stanford University Network. These three companies all started from the same hardware design. Cisco took this design and the original software for running the Stanford networks (some allege they stole it) and kept adding on to it. The 68000 had no MMU, and therefore provided no protection of one process from another- any process could write to any part of memory.
The problem is that the software still has this in its genes. While IOS will make use of modern MMU's to do some level of protection (such as marking read-only the text segment), at its core its still a "every process is fully trusted" design. Now, this does have some advantages- in the old days when the forwarding was all done on the CPU in the interrupt context this was a huge win. Saving all the state and MMU context switches could really lower performance.
The drawbacks, however, are pretty bad IMHO. Since there's no separation of processes, any one process can bring down the system. If BGP was running under Unix, and it ran in to a problem where it would seg fault, under IOS the entire system would panic and reboot. IF it happens to catch the error, which is much less likely to happen because there's no separation of processes and what memory resources belong to that process as opposed to other processes.
The monolithic nature of IOS also tends to breed lax programming practices. Who needs to ensure that everything is tip top when everything is self contained? There's a certain darwinian pressure that gets placed on a system when anyone can write code for it and expects the system to stay up and running like Unix. Under IOS, none of that exists. As a matter of fact, the pressure is in the opposite direction- when you write something that crashes the system- don't do that. Furthermore, the code tends to largely interact with only a few other implementations, and the one it interacts with the most is itself (cisco's talking to cisco's). Not a lot of pressure to find those odd ball corner cases and fix them... Just the kind of corner cases that are the most likely to result in exploitable bugs.
So, are there security problems with IOS? You'd better believe it. All you have to do is peruse the BugTracker database and look for bugs that cause a crash. Things like "malformed SNMP request causes crash" are prime candidates to exploit.
The only question is how you interpret it. The first interpretation, created by Einstein, Bohr and other dignitaries of the time, was the "Copenhagen Interpretation" which requires an "observer".
Actually, Einstein was adamantly against this view of the particle/wave phenomena. He essentially felt that quantum mechanics represents an excellent statistical representation of what happens on a small scale, but that the statistical methods used to model quantum physics are not at all what really happens. This is where his famous quote of "God does not play dice" comes from. He felt that everything was deterministic, not probabilistic, as the Copenhagen Interpretation requires.
Makes for some fascinating implications. "Quantum computers" are predicated on this probabilistic nature of reality. I suppose we'll finally get the answers to these long standing questions when someone is able to build a fully working QM computer and not just the "toy" structures that are built now. It'll be interesting to see what's really down there- a fantastically fine grained deterministic fabric of space, time, and matter... or the QM perspective of a continuous realm.
Lots of little clues everywhere, and I'm sure it'll all seem obvious in retrospect. But right now, it's a pretty fierce debate.
Apple made some very questionable hardware decisions. They made the original Mac non expandable (no slots, you even needed a special tool to open the case, didn't change until the Mac II), even though expansion was a key to the Apple II's success (they totally ignored their hacker roots).
I strongly disagree with this. I consider the design decisions to make the Mac as simple as possible a stroke of genius. You have to evaluate it in the context of it's time. I'm not aware of any machine before the Mac that nailed it all in terms of user centric ease of use in a simple package.
Cast in the light of what was currently available, this was very bold. Back then you bought a computer, and computer meant a pretty garish case that contained a power supply and a logic board that contained a CPU and space for ram. Want anything else? Buy it and install it. Serial ports? Video display? Color? What kind of monitor? Remember the fun you had turning the computer on and off, pulling out the cards, moving those little jumpers around, trying to get all that stuff that was never designed to work together to function peacefully? This is the way things had always worked up until that point, so it was very comfortable to keep doing the same thing. And the market at the time, geeks.... kinda liked all that futsing around.
Now, do you remember setting jumpers on the mac? No? Do you remember having any of the problems that plagued early PC's? No? None? You mean, it just... worked? And the user interface made it easy enough for your mom to use?
Brilliant. On so many levels. To do something that no one else was doing and be willing to turn your back on your roots for what you think the future will be? I tell you what, I wish more people had balls that big in the computer industry. Which represents a larger market? Hard core geeks who like moving jumpers around or mom and pops who just want to send an email without remembering ESC F1 x : in order to edit a different line of text?
They made their own networking hardware (localtalk) which although cheaper was slow, and had connectors which were non-locking (causing endless technical support problems).
Well.... all I can say is you've never had the joys of administering a large campus with Apples and PC's. "Endless technical support problems" with localtalk? Tell you what, you go get out your old ISA SoundBlaster and ISA NE2000 card and then get Windows to.. well, run, and then we'll swap stories about a connector popping loose.
The Mac has had its share of low level problems and incompatibilities. Some of the famous ones include a bad virtual memory implementation and 28 bit vs. 32 bit addressing
Can't argue that the early MacOS had a terrible time moving in to modern times and memory management. Who are we kidding? It never did. It died and was replaced with OSX.
Again, you have to consider this in the context of when it was designed. The 68000 did not support virtual memory. It could not restart an instruction where the page fault occurred even if it had an external MMU. The biggest improvement the 68010 had was a slightly different machine state stack frame that you could use to restart the instruction that caused the page fault. That and a small tweak to the instruction fetcher, I think, that gave you a 10% speed boost.
And it was 24 bits, not 28 bits. In retrospect, it's pretty easy to see who was at fault (the developers), but at the time the 68000 was one of the first commodity CPU's that had a 32 bit wide address space. Now, the problem was that the chip packaging at the time just couldn't pack enough pins in to carry the top eight bits. And 24 bits, that's 16 megs, which at the time would have meant a second mortgage on your house anyways. The problem was the 68000, instead of doing the correct thing and enforcing all 0's in that upper byte.... just ignored it. Anything was valid, and so programmers started stuffing some information in to that extra byte.
Ummm... no. You have no idea what you're talking about. If you had said "used" (as in past tense), then you'd at least be close. Still wrong, but close.
Actually, you're wrong too. HotMail, before they were bought by Microsoft, used FreeBSD for the front ends and Sun with Solaris for the backend databases.
The first thing to migrate over was the front end, and the first iteration of it was a total disaster. There was actually a good internal Microsoft white paper that made it out about the lessons they learned about running NT in a datacenter environment. Chiefly that it's hard to remote administer a system that has a GUI interface for everything.
Seriously, the first thing that went through my mind was:
Someone built a remote keyless radio lock picker, that tries hundreds of codes.
A smart car designer would have the remote keyless system go in to fail safe if too many attempts were made and require some kind of resync, like when the key is in the ignition and it reads the ID off the key.
If this hypothesis is true, I'd bet money that it was all one type of system that got screwed up.
Slashdot Mirror
Thanks for the tip, I honestly didn't know that site existed.
If I had any moderator points, you'd get them. I think this comment is more insightful than it appears at first glance. While I applaud the articles root authors desire to help an open source project, it is a slightly different way of approaching the problem. Maybe the best way the root author can help open source projects is to "meta-help" them- make it easier for open source projects that need help in areas that are beyond their skill sets to connect with people willing to provide that help. For example, in my open source project, I've got the programming, HTML, and documentation needs pretty much covered. However, I do need help with the following:
o Art. I can't draw stick figures. But I do need a few pieces of art such as an "Icon" in various forms and resolutions. Possibly a few "icons", such as a "represents the whole project", and an icon for different sub-projects (i.e., something like Mozilla -> Firebird, Thunderbird).
o Translation. It would be nice to do some internationalization. There's actually a few levels to this, as well. There's some relatively simple tasks, such as localizing approximately two dozen run time error messages, all the way up to a major undertaking like localization of the documentation.
There's obviously a few more high level categories that apply to most projects as well (porting, testing on platforms not readily available to the developers, etc). So, maybe some kind of "open source job site" where project owners can post "jobs" and include details like the type of license that is required for any contributions.
TransactionKit is another lockless highly concurrent data structure, specifically a hash table.
You are bang on.
Display coalescing was introduced way back in 10.4. This was well documented, and as the Firefox developer points out, there's even tools provided to enable and disable this behavior to see if you're being limited by it.
While I don't know all the details, I would venture to say that far from Apple "Secretly Crippling Non-Apple Software" (which they conveniently provide release notes and debug tools with the stock Xcode tools for this secret behavior), this has exposed a serious performance problem in Firefox.
To put it another way, display coalescing will effectively penalize apps that are rendering more updates that are physically possible to display. As an extreme example, this roughly equivalent to rendering / writing 60 frames of video to the display in 1/60th of a second, which can only possibly display one of those 60 frames. The rest are just wasting CPU, GPU, and bandwidth resources which could be better spent doing other things. Display coalescing will cause an application to "stall" if it's forcing too many updates, the call to flush the buffer just won't return until the the current frame has fully rendered.
Mac OS X prior to 10.4 did not enforce this, and so as one of those compatibility trade-offs, display coalescing is turned off by default when certain conditions are detected. I believe anything linked prior to 10.4 will trigger it, and carbon apps. Carbon is essentially for those who are unwilling to (almost literally) join the 21st century.
Just how secret can it possibly be with publicly available release notes published years ago?
http://developer.apple.com/technotes/tn2005/tn2133.htmlThe case for the Itanium is that the reason it failed in the Wintel world
Wrong. The Itainium never competed in the Wintel world. It was designed to captalize on the high margin server chip business (Alpha, HPPA, Sparc, etc). It failed in that market because frankly, it sucked. Tragically, this ended up killing the Alpha CPU due to the DEC/Compaq/HP shinanigans. The alpha was the speed king, and even though there's been virtually no work done on them since 2000, they're STILL some what competitive.
was the difficulty of programming for it, notably its ramant use of out of order instruction capability.
Wrong. Programming for it is like any other chip- you use a compiler. Now, writing compiler back ends for it is very difficult because it's a VLIW design, meaning each 'instruction' is actually a bundle of multiple instructions, one for each exposed unit (I think there's 2 integer, 2 fp, and 1 branch per bundle).
This also makes your other point very, very wrong- the compiler is responsible for extracting the instruction level parallelism from the code stream, not the CPU with such tricks such as out of order execution.
Going Itanium could let them leapfrog the x86 world and have more headroom for growth.
Have you actually looked at the spec scores? The only thing the Itanium is better at is floating point, and not exactly by a killer margin, either. Opterons trounce it in integer performance, and are competitive in FP. And once you factor in price/performance, forget about it.
Surely intel has some response to the Cell. Are they going to cede the entire video game/ digital hub market to xbox, sony and the cell?
What, exactly, are they going to do? Design some killer chip combo and then ask pretty please, with suger on it, would you ditch your current xbox/ps3 design and switch to our stuff right now? Are they going to cede the entire video game / digital hub market to xbox and sony? It already happened, nothing to be done about it but maybe hope for a spot in five years.
True. But bring a jacket, it's cold up here in Canada.
To further this line of thinking, I would guess there's an even more likely possibility: The husband did actually buy the fire starting items in question and brought them home. Once home, the kids had ready access to them.
Also, it wouldn't surprise me if there were a law or regulation preventing the disclousure of a minors identity in such a situation. Or, assuming it is one of the kids, perhaps age and the facts of the matter played a part in the decision to not release their name. This could make a lot of sense under the right circumstances. How accountable is an eight or nine year old to such actions? And then to (potentially) have this show up during background searches when applying for jobs. While some jursidictions may allow for a minors record to be expunged, news paper clippings aren't quite as easy.
Further more, if the above is roughly true, the husband probably willing gave his safeway club card over and allowed them to obtain whatever records they wanted. Considering this, the husband might not have even realized the potential connection between the items bought and the physical evidence. Ironically, assuming it was one of the kids, this may have helped ferret out the real instigator because there was some strong circumstantial evidence that the required items were in the house.
Wow. You're right. Bugs are expensive any way you measure them. Since you're the team lead and sr. programmer, I'd like you to stop putting bugs in our products code. And since you're going to be writing less code (total code = useful code + bugs), you should be able to get the product done much earlier. HR will be having a chat with you about your compensation, what with doing less work and all that extra expense you've been causing us all this time.
Dumbass.
Let me grab a chair while we wait for your next enlightenment. Next thing you know you'll move the release date up six weeks because that would give us six more weeks of profit.
Some of the best advice I ever got was understand the difference between activity and acomplishment and avoid people who don't.
First order of business is "What is the problem?" This is never really adequately defined, near as I can tell. Some vague references to some "problems" with TCP without any objective data to support the statements. Since a solution is being proposed to a problem, we need some way to measure the problem objectively. How else can you tell if your proposed fix is better or worse than the baseline? Since the problem is never defined in any detail, and certainly never to a point of which you can measure, and the fact that there is no objective data, makes the whole thing totally suspect right from the start. In a nutshell, extraordinariy claims without extraordinary proof
Regardless, there are some nuggets here and there that we can pick apart (from the website):
#1 Rateless Internet is an Internet transport protocol implemented over UDP, meant as a better replacement of TCP. TCP's legacy design carries a number of inefficiencies, the most prominent of which is its inability to utilize most modern links' bandwidth.
#2 This problem stems from the fact that TCP calculates the congestion of the channel based on its round-trip time. The round-trim time, however, reflects not only the congestion level, but also the physical length of the connection. This is precisely why TCP is inherently unable to reach optimal speeds on long high-bandwidth connections.
#3 A secondary, but just as impairing, property of TCP is its inability to tolerate even small amounts (1% - 3%) of packet loss. This additionally forces TCP to work at safe and relatively low transmission speeds with under 1% loss rates. Nevertheless, our extended real-life measurements show that highest throughput is generally achieved at speeds with anywhere between 3% and 5% loss.
Point #1 is a claim without any evidence to back it up. Now most of us may think there is a hint of truth to this from experience. The danger lies in making an assumption that the problem is TCP. It could be a bad implementation of the stack you're using, some kind of packet loss in the path, or you're just trying to send too much data given the conditions of the test (ie, a Pentium 90MHz trying to fill a 10Gb/sec pipe). There's just too many variables that influence the amount of link utilization to make such a generalized statement that "TCP is inherently unable to reach optimal speeds on long high-bandwidth connections". There was a time when two Sun machines sitting next to each other couldn't utilize the entire capacity of a half duplex ethernet, for example. Yet it's not uncommon to have more bandwidth to your home via cable/dsl and make full use of it even on cross country/inter continental links these days without a whole lot of change to the fundamentals of TCP. Therefore, it's unreasonable to conclude that TCP is the cause of any of the problems, perceived or real, considering the history of TCP and it's scaleability over time and total lack of any effort to rule out other causes.
Point #2 is a case of where a little bit of knowledge is much more deadly than none at all. I'd be willing to chalk this one up to a marketing person's copy than any particular design insight by the developers, but it's spooky that it's there. At a fundamental level, queueing theory tells us that the average time for a unit to be processed in a queue is related to the depth of the queue. If there's nothing, or effectively nothing, in the queue when your packet arrives, there is no delay in sending the packet. However, the delay grows as the depth of the queue grows. This shows up as variability in the round trip times of packets, relative to each other. Also known as "jitter". Therefore, no jitter means there are no queueing delays, which means that there isn't much traffic competing for access to the links. High jitter means there are a lot of packets competing for access to a link, and therefore much more likely to be c
What? There is nothing in IPv6 about this. You can do this right now, today, with IPv4 by having a flexible queueing methodology and flexible packet pattern matching systems. Violla. Any packet destined to network 1.2.0.0/16 that is TCP and port 80 no gets dumped in the high priority queue.
QoS is also the perfect snake oil. In a practical sense, QoS only "kicks in" when there's contention, when there's more data that needs to squeeze in to the pipe than can fit. QoS makes the choice of which packet gets to go over all the other packets waiting to go.
In other words, the only time QoS is of any good is when you are on a over subscribed, saturated network, where there isn't enough bandwidth available to meet demand. In simple terms, the network is broken, and QoS just helps pick who gets screwed the least.
Lastly, routing will be simplified because the IPv6 information header on each packet is far more flexible and can contain more detailed information than an IPv4 header thus allowing for faster routing of data across a network or the internet. Currently, most routers need to maintain as many as 48,000 different routes in their routing tables just to effectively route data that passes through them. IPv6 reduces this number by at least 75%.
This, too, is just flat out wrong. The only way this works is if you have a "clean slate" and parcel out IP addresses in a country/provider hierarchal fashion. Want to move providers? You get new IP's, out of their block. Want to multi home? Well, that kinda blows the efficiency right out of the water because now your network is no longer contained within the providers supernet, you have to announce your individual network both via your provider and where ever else you're peered. Therefore, you just added networks to the global routing tables.
Now, quick show of hands... how many of you want to run your systems off a single homed, single provider only network? And please, none of this god awful "let the router pick which source IP to use!" crap.
Also, if you're worried about IPv6 requiring you to change all of your software, learn new protocols, new methods of connecting, new ways of sending and receiving data or anything like that, fear not. The only thing really changing with IPv6 over what was in IPv4 is that you now have a larger address space which allows for more network addressable IP addresses, a more flexible header and packet system, and faster routing.
Yea, you don't have to change a thing. Not any of your software, or nothin'. Of course, you do need a whole new IP stack to talk IPv6, but that's pretty minor right? Windows folks can make this change by simply cracking open their registries and changing the IP Version key from 4 to 6. Ta da!
Faster routing? How's that? Does it make sense to anyone that looking up a 128 bit address is going to be faster than looking up a 32 bit address? There's more to look up.
Furthermore, all routers worth their salt use hardware accelerated forwarding engines these days. Modern BiCAM's or (nearly always) TCAM's can do single cycle lookup of an address out of a potential 512K entries. It doesn't matter how many entries there are, it can always do find the correct match in a single cycle. And 512K entries is a bit more than a default free routing table (~140K entries) that's common today, so there's no worries there.
The catch is, most of these hardware lookup engines are hard wired for IPv4, and can't easily be extended to IPv6, which means the packets become exception packets and need to be dealt with by the CPU. The CPU lookups are orders of magnitude slower than the hardware lookups. This means that performance for IPv6 goes right through the floor for most routers. Newer routers/blades are starting to come with IPv6 hardware accelerated, but there's an awful lot of infrastructure out there that has no IPv6 hardware acceleration.
Therefore, for most people, IPv6 will initially result in a signfigicant performance drop in terms of packets per second over IPv4.
In summary, true randomness exists as a very fundamental result of the laws of nature, and won't go away no matter how good our measurements get.
Well, let's be clear here. Our best models (ie, quantum mechanics) have a statistical nature at their core. They are quite capable of predicting a large body of phenomena. Not all observed phenomena, and there's a few odd points here and there, but it's pretty damn good.
This does not, however, mean that this is the way the universe works. It's just a mathematical model. Newton's models gave us VERY good results, but it ended up folding. Not quite folding, but being superceded by something that was a bit more accurate.
So, given this, the "uncertainty principle" is the best we have. It's also somewhat axiomatic. It just is. But why? What gives rise to it at a very fundamental level?
So, it works for now, but that doesn't mean that's the way things are. Who knows? Maybe at a fundamental level, at plank scale and time, it just looks like that because we are fundamentally incapable of making such tiny, minute measurements that the whole thing is really just a big pinball machine that changes depending on the initial conditions. It may seem the same to you and I, that atom right there letting go of that photon... but it may be at the plank scale the difference of between say, earth and mars.
Actually, 8 sockets would be correct. There's three flavors of opteron: single cpu (1XX), dual cpu (2XX), and eight cpu (8XX).
Of course, nearly all the motherboards you can buy today only use four of the eight way SMP capability. The slashdot title is a bit misleading, they're only demoing a 4 socket / 8 core version today but an 8 socket system is doable right now, today, with the 8XX series CPU's.
As the article says:
So what today might be an eight-way server will potentially become, mid-2005, an "eight socket" server with 16 processing cores.
Actually, this isn't possible. As a matter of fact, you make things considerably more insecure by doing just that.
Say a group of people fit this "profile". Now, things being the way they are in the world, it only catches 80% of them. So, if any one of them were to pick up a bomb and do the dirty deed, well, it's unlikely they'll make it.
Here's where the problem begins. It's pretty obvious if you've been "tagged" by the system. So, why not send your merry little band of enthusiasts through the system a few times? Explicitly not doing anything illegal.
Guess what? Those who are tagged by the system don't get to go on the big outting. Those who remain are pretty much free and clear.
The other problem is.... that profile is picking out people for a reason. Simply find a way to be "something else."
As an example... the profile says that most/all of the terrorists are men. Suzy, with her new baby, would never be a terrorist. Get the picture?
So, basically, these types of systems are fundamentally useless against trying to detect what it is you're looking for. It's trivial to circumvent it with a determined group.
Then there's the problems. Guess what, you get an awful lot of "false positives" from the system. And most people aren't terrorists (19 out of six billion, remember). Once you're in the system, what's the incentive to get you out? You think a screw up at the DMV is bad, well, my lubed up, latex covered fingers are going to make you wish for a hot and muggy, no air conditioning, babies crying everywhere, no line moving DMV.
Oh... and not just this time, EVERY TIME. Good luck convincing people you're "not a terrorist". As a practical joke, we'll put Timmy on the list. Oh, won't he have fun on his flight to Chicago, that'll be a riot.
As every God fearing, christian, patriotic, white, American (God bless her), middle aged male knows it's FOXaroundtheworld@foxnews.com at the Fair And Balanced (tm) news reporting agency of Fox News
Possibly. But since you seem to acknowledge that a given population has a contrary view point, do they have a valid reason?
but I have no problem with the FBI being able to monitor conversation between criminals.
Sure. I'd venture that on a pure principle level, most people don't.
The problems usually begin with what "criminal" means. The ones who write the law have a pretty good idea of how they want the law to be used, and at the start everyone thinks it's a super idea. "Criminal" is written pretty broadly, trying to cover "the bad guys".
As the cliche goes, if you're not a criminal, you have nothing to worry about. If you're paranoid, I'd guess you shut up anytime a cop comes within hearing distance.
Later on, however, the enforcers would really like to make use of this provision because it's pretty potent. So the definition of "the bad guys" shifts a little through any number of legitimate means, such as changing the scope of what a criminal is to adding new crimes that fall under the original scope.
Then, a set of events takes place and all of the sudden it's really bad to be a "terrorist". And a terrorist is sort of loosely defined, but definitely someone who is against "the state" and what it represents, using any and all means at their disposal, including disinformation and propaganda.
Do we have a right to privacy? Sure. Do we have a right to keep criminal conversations private? No. Is this subject to abuse? Sure. Will we be abused by criminals who conspire in private? Of course.
What's a "criminal conversation"? Because history assures us with countless examples that those who make the decision on what a "criminal conversation" is rarely do it with YOUR best interests in mind.
Is discussing with other like minded individuals your displeasure with the current George W. Bush administration and planning activities to educate the public on the facts and what they can do to kick him out of office a "criminal conversation"?
Want an example? The PATRIOT act, which did away with such minor things like habeous corpus (considered by many to be the cornerstone of our justice system and made no one above the law, one of the fundamental checks and balances ) and passed to deal with "extraordinary threat" in these "extraordinary times"..... being used for a copyright case. Legislation that bypasses most of the fundamental US Constitutional rights would NEVER be applied to anything frivolous.
Given the choice between giving criminals the freedom to conspire in private or the ability of the FBI to wiretap criminals, I've no problem opting for the former.
This is the beauty of the whole thing right here. Trivial means in the form of encryption exist that totally negate any benefit law enforcement would gain from such legislation. Most likely, these days, all the necessary tools exist on your computer right now (openssl).
The only people that this would be of assistance against are... well, idiots. Since you know you're going to be discussing things of particular interest to law enforcement, and they have the means to intercept it, it's in your interest to encrypt your communications. So, from a practical sense, the only information you're going to get out of this is that two people spoke to each other which is useless in court.
So... now what? We now have a system in place that's capable of catching none but the most utterly incompetent criminals and can be abused by the government against law abiding citizens.
I know! Let's outlaw encryption. That'll learn 'em.
In any case, the net is a public place. Nothing there is private.
This seems to be particularly specious reasoning. By the same token I can say that the entire planet is a public place, ther
Where did you get these numbers? Yahoo shows that they have 2.37B in cash, and 1.47B in debt.
Now, mind you, this varies from state to state, country to country, but in the US there are certain labor laws against this type of abuse.
First and foremost you have to understand what these two terms mean:
Salaried
Exempt
An exempt employee is always salaried.
A salaried employee is not necessarily exempt.
There is a difference. A huge difference. And I'd bet nearly all of you didn't understand the nuance. Guess which one your HR department has you marked down as, and I bet you never throught to even challenge it.
Exempt applies to a certain class of workers. IANAL, but roughly this means that you are (ta da!) exempt from certain labor regulations, such as number of hours worked and whether or not you get any over time. Exempt employees are, by definition, salaried. Believe it or not, most of the tech jobs don't fall under the "professional" exemption. This varies from state to state, states being able to offer stricter regulations than the federal mandates. California tends to favor the employee, not the employer. As a rule of thumb for this group, you can be exempt if you're an executive or have an advanced degree and the degree is required to work in your profession (ie, doctors, etc)
Salaried means you get a fixed pay rate per week. If you show up for 20 minutes a day, or even one day, you are required to get your full weeks salary. You can not be docked for hours missed unless it's for a full day, and there's limits on that too.
Of particular interest is the case of the salaried employee who is non-exempt. A non-exempt, salaried employee can work less than 40 hours a week but still must be paid for 40 hours. However, working more than 40 hours (or by your states laws) you are required, by law, to be paid for working those hours.
I'll bet you haven't been, huh? Keep track of those extra hours, and let your boss know. Should you be discharged, ask for your back pay. If they chuckle at you, contact your local department of labor and say you have an unpaid overtime claim. You're likely legally entitled to it, and the department will investigate and make a determination.
You can also be exempt and loose your exempt status unless the company is mindful of the laws. Are you exempt and you've been asked to take partial days off for vacation or sickness? In your companies eagerness to save itself $100, they likely lost your exempt status and opened themselves up to oweing you tens of thousands of dollars in back pay in overtime.
Now, as for the original question... that's kind of interesting. If you're in California, they may be liable for paying you while you at home. Possibly 24 hours a day.
IMHO, companies that are that f'ing cheap deserve exactly what they get.
Compensation for standby time
Excessive OT
Compensatable hours worked
The use of pagers
California Labor Code
No. IOS isn't based on any operating system. IOS has very little in the way of modern opperating system services. As a matter of fact, it's a cooperative multitasking system- any one process can lock up the system or stamp on the memory of any other process.
It's because of it's historical roots- these types of embedded systems were easier to write (at the start) and faster (less overhead, faster context switches). Today, I think it's a huge liability.
Yes, provided it's solid code. So the obvious question is: is it solid code? What makes for solid code? I'm of the opinion that it is far from 'solid' code for two main reasons.
The history of the code base.
It's monolithic nature.
IOS started out on the same CPU board as Sun (and SGI) computers: The Stanford 68000 board. Remember what Sun stands for: Stanford University Network. These three companies all started from the same hardware design. Cisco took this design and the original software for running the Stanford networks (some allege they stole it) and kept adding on to it. The 68000 had no MMU, and therefore provided no protection of one process from another- any process could write to any part of memory.
The problem is that the software still has this in its genes. While IOS will make use of modern MMU's to do some level of protection (such as marking read-only the text segment), at its core its still a "every process is fully trusted" design. Now, this does have some advantages- in the old days when the forwarding was all done on the CPU in the interrupt context this was a huge win. Saving all the state and MMU context switches could really lower performance.
The drawbacks, however, are pretty bad IMHO. Since there's no separation of processes, any one process can bring down the system. If BGP was running under Unix, and it ran in to a problem where it would seg fault, under IOS the entire system would panic and reboot. IF it happens to catch the error, which is much less likely to happen because there's no separation of processes and what memory resources belong to that process as opposed to other processes.
The monolithic nature of IOS also tends to breed lax programming practices. Who needs to ensure that everything is tip top when everything is self contained? There's a certain darwinian pressure that gets placed on a system when anyone can write code for it and expects the system to stay up and running like Unix. Under IOS, none of that exists. As a matter of fact, the pressure is in the opposite direction- when you write something that crashes the system- don't do that. Furthermore, the code tends to largely interact with only a few other implementations, and the one it interacts with the most is itself (cisco's talking to cisco's). Not a lot of pressure to find those odd ball corner cases and fix them... Just the kind of corner cases that are the most likely to result in exploitable bugs.
So, are there security problems with IOS? You'd better believe it. All you have to do is peruse the BugTracker database and look for bugs that cause a crash. Things like "malformed SNMP request causes crash" are prime candidates to exploit.
Actually, Einstein was adamantly against this view of the particle/wave phenomena. He essentially felt that quantum mechanics represents an excellent statistical representation of what happens on a small scale, but that the statistical methods used to model quantum physics are not at all what really happens. This is where his famous quote of "God does not play dice" comes from. He felt that everything was deterministic, not probabilistic, as the Copenhagen Interpretation requires.
Makes for some fascinating implications. "Quantum computers" are predicated on this probabilistic nature of reality. I suppose we'll finally get the answers to these long standing questions when someone is able to build a fully working QM computer and not just the "toy" structures that are built now. It'll be interesting to see what's really down there- a fantastically fine grained deterministic fabric of space, time, and matter... or the QM perspective of a continuous realm.
Lots of little clues everywhere, and I'm sure it'll all seem obvious in retrospect. But right now, it's a pretty fierce debate.
I strongly disagree with this. I consider the design decisions to make the Mac as simple as possible a stroke of genius. You have to evaluate it in the context of it's time. I'm not aware of any machine before the Mac that nailed it all in terms of user centric ease of use in a simple package.
Cast in the light of what was currently available, this was very bold. Back then you bought a computer, and computer meant a pretty garish case that contained a power supply and a logic board that contained a CPU and space for ram. Want anything else? Buy it and install it. Serial ports? Video display? Color? What kind of monitor? Remember the fun you had turning the computer on and off, pulling out the cards, moving those little jumpers around, trying to get all that stuff that was never designed to work together to function peacefully? This is the way things had always worked up until that point, so it was very comfortable to keep doing the same thing. And the market at the time, geeks.... kinda liked all that futsing around.
Now, do you remember setting jumpers on the mac? No? Do you remember having any of the problems that plagued early PC's? No? None? You mean, it just... worked? And the user interface made it easy enough for your mom to use?
Brilliant. On so many levels. To do something that no one else was doing and be willing to turn your back on your roots for what you think the future will be? I tell you what, I wish more people had balls that big in the computer industry. Which represents a larger market? Hard core geeks who like moving jumpers around or mom and pops who just want to send an email without remembering ESC F1 x : in order to edit a different line of text?
They made their own networking hardware (localtalk) which although cheaper was slow, and had connectors which were non-locking (causing endless technical support problems).
Well.... all I can say is you've never had the joys of administering a large campus with Apples and PC's. "Endless technical support problems" with localtalk? Tell you what, you go get out your old ISA SoundBlaster and ISA NE2000 card and then get Windows to.. well, run, and then we'll swap stories about a connector popping loose.
The Mac has had its share of low level problems and incompatibilities. Some of the famous ones include a bad virtual memory implementation and 28 bit vs. 32 bit addressing
Can't argue that the early MacOS had a terrible time moving in to modern times and memory management. Who are we kidding? It never did. It died and was replaced with OSX.
Again, you have to consider this in the context of when it was designed. The 68000 did not support virtual memory. It could not restart an instruction where the page fault occurred even if it had an external MMU. The biggest improvement the 68010 had was a slightly different machine state stack frame that you could use to restart the instruction that caused the page fault. That and a small tweak to the instruction fetcher, I think, that gave you a 10% speed boost.
And it was 24 bits, not 28 bits. In retrospect, it's pretty easy to see who was at fault (the developers), but at the time the 68000 was one of the first commodity CPU's that had a 32 bit wide address space. Now, the problem was that the chip packaging at the time just couldn't pack enough pins in to carry the top eight bits. And 24 bits, that's 16 megs, which at the time would have meant a second mortgage on your house anyways. The problem was the 68000, instead of doing the correct thing and enforcing all 0's in that upper byte.... just ignored it. Anything was valid, and so programmers started stuffing some information in to that extra byte.
Actually, you're wrong too. HotMail, before they were bought by Microsoft, used FreeBSD for the front ends and Sun with Solaris for the backend databases.
The first thing to migrate over was the front end, and the first iteration of it was a total disaster. There was actually a good internal Microsoft white paper that made it out about the lessons they learned about running NT in a datacenter environment. Chiefly that it's hard to remote administer a system that has a GUI interface for everything.
Someone built a remote keyless radio lock picker, that tries hundreds of codes.
A smart car designer would have the remote keyless system go in to fail safe if too many attempts were made and require some kind of resync, like when the key is in the ignition and it reads the ID off the key.
If this hypothesis is true, I'd bet money that it was all one type of system that got screwed up.
SGI was also interested in the Amiga's chips, but that obviously never got very far.