Even if you are not asking for a position in sales, you are selling a product: yourself.
There are two things any company is looking for:
o The ability to fulfill the requiremetns of the position
o Team fit
The first can be satisfied by work experience and paper credentials, if you have them. Depending on your ability to sell yourself as being able to do the job - your reputation in the field of endeavor (if you have one), your paper credentials coming from a place with a reputation in the field, your paper credentials with regard to union and other organization membership with a reputation in the field, and so on - you may or may not end up needing to have references that can be checked, letters of recommendation, and so on.
The second is a matter of personal prejudice, and whether or not you rub the person/people interviewing you the right way or the wrong way.
If you get to an interview, then your paper credentials, on face value, are sufficient that they expect that - if you did not lie about your capabilities in your resume or on the application - you can do the job. So the purpose of the interview is almost entirely (80%) a matter of determining whether or not the organization wants you, as a person, working there, and only a little bit (the remaining 20%) about whether or not you lied on your paperwork.
Your reference to "programming classes in high school" implies that you are either currently in high school, or a recent graduate, and either are not yet in college, or are recently enough enrolled that you can't point at classes from your college experience yet, instead.
No one is going to be impressed with your high school technical credentials, unless you went to a magnet school, attained some type of certification, or can demonstrate involvement in some level of professional project. Without that, having done well in a high scholl technical class merely means "attended class regularly, did not make a nuisance of themselves, turned in most of their homework, did not outright flunk tests".
If you are dying to demonstrate your "Mad Technical Skillz", take a job where there will be opportunity to demonstrate them, but for which they are not a requirement for the job you take. If you have them, and the place employs people like that as well, then your demonstration will be enough. Otherwise, consider going to college - your opinion of your "skillz" is probably higher in your mind than in reality.
In terms of getting the jobs that you've applied to - if you've genuinely applied to 12 fast food places, and not been hired at any of them, there's something wrong with _you_, in terms of employability. If you've genuinely applied to 27 total places, and only been interviewed twice, then the problem is likely your appearance - cleanliness (breath, B.O.), behaviour, clothing, hair style, piercings, tattoos, or something similar. All of these are part of being able to sell yourself to an employer, and all of these would have either nixed an interview happening in the first place, or if you escaped the screening process, sunk your interview immediately.
In addition, there could be other factors; if you are currently in high school, or graduated early, you could legally be too young to work. If you've indicated that you are going to college out of state, and this is "just a summer job", then you are a fly-by-night employee, who will get trained enough to be worth your wage, and just as you become useful, are expected to take off for parts unknown.
Frankly, even if you are in high school, but old enough to legally work (17+), it's not that hard to get an entry level job. You just have to sell yourself.
A shower, dress slacks, a casual shirt, socks without holes, normal shoes (not motorcycle boots with 2 pounds of metal with scrollwork on it), etc. indicate to your potential employer that you take the opportunity to work for them seriously, and that you're willing to dress up to attt
Bounded time, malloc, new, using GC in a project..
Actually, you can run a malloc or a new in bounded time; the issue is whether or not you have an allocator that's capable of doing it or not. If you preallocate objects to your zone, you can perform the operation in O(1) - the amount of time to take something off the free list - and you can do it without locking, so long as you utilize per-CPU pools for your object freelists. If you want to grab one and the freelist is empty, you can fail the operation and force it to retry later (or you can decide not to reenable interrupts until the top end has completed processing and returned the free work item to the interrupt handler one-item-pre-cache).
My personal preference would be to preallocate as much as I will need to run the operation to completion - and no more. It's OK to have a data source that's noisy and generates a lot of work items, but only if it happens at soft interrupt.
For things like network drivers, the delyed reenabling of interrupts is the best bet. First of all, you likely want to take one interrupt and poll like hell until there's no more data; an 8MHz PC can keep up with 115K baud serial data (barely) if you do that, whereas direct interrupt processing will cause it to lose it. Second, you don't want to reenable the interrupt to let it reinterrupt you if you can't drive the data all the way to the application anyway; reenabling the interrupts prematurely leads to problems like receiver livelock, which has been known about for years (google for "livelock" "networking" "DEC" "WRL" "Jeff Mogul").
As far as using GC in a project, I've done it, and I've seen it done (Objective C supports GC in the next release of Mac OS X, as reported on Apple's web pages, so I'm not letting any cats out of any bags). My personal opinion is that once one framework you need becomes "GC-only", there will be no way to make code that correctly operates as both GC and non-GC code. The problem is that programmers are human, and they make mistakes, and if the mistake happens to be that you forget to release some memory, but it's OK because GC catches it, then you will never be able to go to a non-GC world and depend on that code again. For me, that means I can never take that code, or a part of it, and put it into an environment where GC isn't possible because I need to run in bounded time, without debugging it, or doing a full branch path analysis on it and generating test cases to exercise all the code paths; at that level of cost, I might as well just rewrite it from scratch.
A real world example of this was the use of the TSM (Tivoli Storage Manager) Java edition on the Whistle/IBM InterJet (I worked at Whistle, which was acquired by IBM). The TSM had an insane memory footprint, and we never shipped it as a product. While the GC in the Kaffe JVM kept the footprint to about 1/3 of the memory that the Sun JVM's GC did at the time, that was still twice the amount of physical RAM we had budgeted for the box. This was all user space code, but driving up the COGS of a product by 11% on the off chance that we would be able to later sell a service add-on for TSM to a percentage of the people who bought the product on its own merits was just bad business.
The difference between 1 & 2 as you've posited them:
1. Allocating objects on the interrupt handler's stack.
2. Allocating objects in a zone that is reserved for the interrupt handler.
is that in the second case you could suffer from zone exhaustion, and be unable to refill the zone at interrupt time. This may occur because there are no pages available, or because refilling the zone would block, or because the zone of zones is exhausted.
If you could override the allocation with an alloca() to force it back onto the stack, then this would not be an issue; however, the general reason for using zones is to obtain type-stable memory.
[Aside:] You do this to prevent someone else's double frees or use after free from shooting you in the foot: you are guaranteed that the damage will be scoped to the zone, and therefore limited to the object type in the zone. So as long as you are not talking about generic sized zones (i.e. zone allocators typically implement a set of "powers of two" zones for random, temporary allocations), then any problem you have can be located relatively easily, since it's scoped to a fairly small amount of code. [/Aside]
I don't think, therefore, that it's really going to end up very useful to map a zone to an alloca() in the general case, since you might as well use stack declaration or alloca() directly; the exception to this would be object scoped languages (e.g. like the one we are discussing here), to permit abusing the override for a subclass of the object acting as the object type (this would probably be considered "bad form", from my reading about the language).
I have a problem with GC in a systems language... specifically, using GC means that your functions will not necessarily run in bounded time.
For a lot of uses, particularly in user space, this is not a problem, but if you were to kick of GC in an interrupt handler or trap handler, or a number of other places, this would make it impossible for you to implement code that was guaranteed to take at most a maximum number of CPU cycles.
The upshot of this is that so long as it's possible for someone to write a driver that ends up running in your kernel, and which depends on GC functionality to not leak memory, it will be impossible for an OS written in that language to support hard real time.
I have to say that GC is marginally useful for systems work only if you can run it on a system that doesn't need GC -- so that you can get a read out of where and how you are leaking memory, fix the problem, and then disable GC before you ship. In other words, it's a great diagnostic, but only if you can run both GC and non-GC at the same time, and only if you explicitly scope your allocations (i.e. act like you are not running in a GC'e lanuage in the first place).
In other words, the intent of GC is to make programmers not have to know where their scope boundaries are, and you _must_ know this for systems programming tasks. So it doesn't deliver on its promise in a systems context, though it could be a helpful diagnostic for developers.
The primary reason for stack class allocation is that you may need to do your instancing at interrupt time or in a trap handler.
Consider the case where you have a memory shortage (but interrupt stacks are preallocated, per interrupt), and therefore you cannot do an allocation, but want to run the current operation to completion.
Consider also the case where you might be using a zone allocator, and you cannot expand the zone of zones, because in order to do so, you' need to handle a trap at ring 0 in a trap handler (i.e. a user page fault followed by a kernel page fault).
The reason that these things wuld not be allocable at interrupt/trap time is that the allocations may block, and, if they do so, you could effectively end up blocked with interrupts disabled and no way to get back from it.
The alterantive to this is that you would have to fail the request and back out your state all the way back (fail gracefully out). The problem with that approach is that now you have to put error checking around all of your function call graph hat could eventually result in potentially failing allocations, and deal with the performance degradation that might result (speculative execution on a PPC would make this effectively free, but on an x86, you would pay a fairly seiors penalty).
There are three approaches commonly used in handling memory stavation situations:
(1) Block until the memory is available
(2) Fail the allocation request, and be prepared to deal with the failure, and then hope that by backing off, you don't lose unrecoverable state (e.g. if I read a hardware register, that might signal something to the hardware that would preclude me restarting the operation - for example, the AMD Lance Ethernet hardware), and that it's possible to redrive the operation
(3) Djikstra's Banker's Algorithm: allocate all resources that you might need up front, before attempting the operation (this is typically what's done with, e.g. the ring buffers associate with ethernet devices, rather than allocating mbufs at interrupt level).
The instancing of classes on the stack falls under a variant of #3: because you already have the stack preallocated, you are guaranteed that, so long as you do not exceed your stack depth, instancing the objects you need to instance for the lifetime of the transaction you are about to perform will always be successful.
I'm not sure if that's the argument the poster to whom you were replying was referring, but I hope that clarifies things for you.
"Windows Vista is the only one that has a protected kernel space, encrypted memory, and randomized memory locations, keeping the user locked away from their hardware."
I. All modern OSs that run on hardware capable of it have a protected kernel space. Mac OS X has been protected mode from Day one, and BSD and Linux (with the exception of intentional ports to poor hardware, like Palm pilots) have had it since day one (1991 for Linux, 1978 for BSD).
II. Encrypted memory is not that useful, without an embedded MMU to do the encryption. The XBox 360 has this, but common Intel hardware does not. Mac OS X has supported encrypted swap and disk images for several years now, and it's common enough in CS circles to experiment with this stuff, so BSD and Linux have spported it as well. As far as code or data are concerned, without the MMU built into the chip, there's no hope of preventing other software running on the system from simply reading the information themselves, either out of plaintext pages, or out of the CPU cache itself.
Either way, encrypted memory does approximately diddly for increasing actual machine security.
III. The randomization of memory locations in Windows is intended to prevent use of a known address for functional OS routines by exploit code that is already running on the system. In other words, its intent is to simply take away access to library routines. The obvious counter to this is to not use he OS routines, and simply carry around your own. The base assumptions here are that:
(1) The attacker has successfully caused code to rune
(2) The code is running in ring 0, having already defeated everything intended to prevent it getting there
(3) The code will call system subroutines to perform work, rather than carring around its own code for e.g. strcpy()
Carry around your own code to do this work, and the target machine is just as screwed; so I'd say that all they've done is increase the size of malware, not eliminate it.
Face it: the only way to make a machine completely secure while leaving it operational is to go locked down from boot onward, and down that road lies "trusted computing", with its own ability to be abused to take rights away from the owner of the machine.
It was Andrew Tridgell, not Jeremy Allison who founded Samba.
Jeremy has been an amazingly important contributor to the project, but it was Andrew's "AT&T LANMan compatibility code" that started the project .
I know, because I brow-beat Andrew on Usenet until he released it after mentioning it once in a post to one of the news groups, and once it was released, I suggested that he start a mailing list for it (we had a bunch of AT&T WGS boxes that AT&T had donated to the University, they all had LANMan, and I wanted to hook them up to the Ultrix box we had).
Also, I used to work in the cublicle across from Jeremy when he was working at Whistle communications before it was bought by IBM. 8-)
They DO have responsibilities, and ARE punishable.
Punishments include fines, sanctions, and so on - up to and including breaking them up and/or revoking their articles of incorporation.
For example, Western Electric was prohibited from competing for profit in the computer software market (the original availability of the UNIX operating system source code was as a direct result of this, as were the license terms that resuled in Berkeley UNIX and the Lyons book out of the University of New South Wales).
For other crimes, coprorations can be held responsible in the persons of their corporate officers, just as HP is currently being held accountable for obtaining the same information about a number of its board members and news reporters.
The example of the PG&E poisoning the groundwater with Chromium in Hinkley, CA (a small town near Barstow, CA), settling for $333M to 650 plaintiffs (the basis of the movie "Erin Brockovich"), and again in 2006 to another 1,1000 plaintiffs in other rural areas is another good example.
It's very rare for a corporation to have its articles of incorporation revoked However, breakups can and do occur; the A&T breakup was a court ordered punative action under the Sherman Antitrust Acts for the illegal use of monopolistic powers.
The entire point of Microsoft fighting the DOJ in the action that resulted in them being declared a monopoly under the law was to avoid such punative action.
I don't have a ready example of a total disassembly of a corporation, but "the death penalty" is available as a punishment, and is technically capable of being applied by the secretary of state in the state in which the company is incorporated. This would most likely that the form of an action brought by the state attorneys general of that state, resulting in a court order to that effect.
I wasn't going to post in this "discussion", mostly because the original question is blatanly biased, and assumes a particular position is held by the reader, and then asks them to explain it... "So, sir, what would it take to get you to stop eating children?".
However, you're such a blatant appologist that I have to say something.
A corporation is called a "corporation" - and has been "incorporated" - because it has been "given a body" under the law to operate on behalf of a group of persons, and has certain rights AND RESPONSIBILITIES, just as any member of society.
The idea that a company, or its officiers, should put fiduciary responsibility on a pedestal, far above any other responsibilities to the society that permitted its incorporatinon, and on whose sufferance its continued existance depends, is relatively recent. Adherence to a specific duty above all other duties or considerations is the moral equivalent of the "Nuremberg Defense".
If a person can sell their soul, and if a corporation is a person under the law, then surely there are also many recent examples of corporations selling their souls.
When everyone has one, what's the point of stealing one? Who are you going to sell it to?
Your biggest market would be eBay'ing it to nerds who want to write software for it, because of it's general unavailability in first world countries. This option immediately goes away as soon as they ram production and start providing them for higher (but still low) cost to developers who want one to hack code on/play with.
Or to put it in Monty Python terms:
King Arthur: Go and tell your master that we have been charged by God with a sacred quest. If he will give us food and shelter for the night, he can join us in our quest for the Holy Grail.
French Soldier: Well, I'll ask him, but I don't think he will be very keen. Uh, he's already got one, you see.
King Arthur: What?
Sir Galahad: He said they've already got one!
King Arthur: Are you sure he's got one?
French Soldier: Oh yes, it's very nice!
The primary reason AI is seen as unsuccessful is because as soon as some aspect of the problem has been solved and the code works, we rename it to something else: speech synthesis, speech recognition, character recognition, motion capture, genetic algorithms, neural nets, edge finding, adaptive control systems, fuzzy logic, etc. etc..
AI research has been very successful, in general, but in specific it has about as much chance as being recognized as successful as a nuclear power plant has of completing construction under the same regulations environment it was designed in, or a four year lame duck president seeing his "five year plan" followed through to completion.
"we've never paid administrators & teachers so much... and gotten so little"
Corollary: "We've never paid CEOs & janitors of major corporations so much... and gotten so little"
If you think all the tax money being collected "for education" is going to my aunt, a special needs teacher in a moderately run-down school district, or went to my grandmother when she was a public school teacher, I have a used bridge to sell you. Low mileage, one owner, only driven on Sundays.
The money never goes to the line workers, I don't care what business you are talking about.
The big benefits of college (assuming you apply yourself) are:
(1) You lean how to think
Most people don't know how to think; they don't know how to think about solving problems, minimally, or, worse, they actually don't know how to think logically at all.
In college, you can fix the second by taking logic, philosopy, criminal law, mathematics, and other clasess.
The only classes I've seen be effective at fixing the second are hard science classes, particularly physics, but also electrical engineering, and some types of chemistry. Other classes can help, but the softer the science, the less likely there is to be a single correct answer to a question, so the less likely you are to hone your skills at getting from the question to the answer. Physics tends to be particularly good, since you start with the answer you intuit, and then come up with questions to determine whether or not the answer is right - this builds both your reasoning/critical thinking skills and your intuition.
(2) You learn the terminology necessary to talk to peers in a technical field
I work as core kernel engineer for the second largest OS company on the planet. There are maybe two dozen of us at this level, depending on how widely you interpret the team.
There are people who would be involved in your interview process here which, if you couldn't use/regcognize proper terminology for even trivial data structures (what's a B-tree, what's a splay tree, what's a trie, what's a skiplist, what's a doubly linked list, etc.) would be happy to walk you to the door. And that's just getting your feet wet in the interview.
Yes, it's possible to pick some/most of this up by being an apprentice somewhere, but doing that, you're going to get local jargon as well, and you aren't going to be able to distinguish it from the real thing, which is going to make you hard to talk to about complex problems. This factors into your team fit (which is ~80% of getting hired, if you haven't lied on your resume, and you got an interview in the first place).
(3) You learn different ways to solve the same problem
One of my favorite interview situations is to ask someone how they've solved a particularly difficult problem in the past, and then poke at it to see if they've been able to come up with some other ways to solve the problem than I did, just thinking about it from their explanation of things. If I can come up with a dozen ways to solve the same problem, and they can't justify why they didn't think of them, or why those approaches would have been less optimal, I'm not very impressed.
You aren't going to get the ability to do this without either a lot of experience, or the exposure to different teaching approaches and approaches of different teachers to solving problems. You can build this over a large number of years of experience, or you can bootstrap your thinking by going to college (and applying yourself).
(4) You establish contacts with people you will meet again and again throughout your life
Do not understimate the value of this. My first job in my college career was a workstudy job. My next job was a lab aide, helping other people solve their problems (or, more generally, helping them arrive at a workable solution on their own). My next job was a series of contract jobs outside the college, for a person I'd met there (also a student), with a less technical and more business bent. I had other work-stuudy jobs, and I did some introductory lectures on various things like how to use the editors, etc.), but my first post-college job was at a company that was owned by a friend of one of the procefessors there.
Never, never, underestimate the value of the contacts you will make, and the personal network you will build, while going to college.
(5) And even if you only apply yourself enough to get the certificate... you get your union card...my faculty advisor was adamant in calling 4 year degrees "union cards". After more than 20 years in th
As a prelude to this, let me state that I obey the posted speed limits.
-
Eisenhower in fact nationalized the highway system; however, that was not my point.
A previous poster in this thread correctly identified my point, which is that the Federal government uses coercive tactics- specifically, the threat to withold distributing Highway funds collected from the states to a particular state, if some subset of laws in a given set of laws is not passed within the state. On top of this, there's a compact between the states called "The Driver's License Compact", in which the states are legally bound to normalize laws between member states as much as possible. So you get things like a motorcycle helmet law in all compact stats, or a uniform speed limit.
Now in the nationalization process in the 1950's, there were a number of things which happened simultaneously; one was the standardization of lane widths, weight capacity, and overpass clearances for "Mobile Nuclear Command Posts" to be able to tracvel to anywhere in the U.S. over the Federal Highway Sytem. Another was engineering minimum speed capability for the Federal Highways: all such highways are required to support vehicles moving *at least* a minimum set speed (initially, 60 MPH) to control maximum time from incident to response, so there are engineering requirements on grade on curves, lengths of curves, bridge carrying capacity, etc., etc., for Federal Highways. At the same time, a funding requirement for a state law was imposed called the "Basic Speed Law" (that's it's name in California, Montanna, and Utah; other states call it other titles).
It's actually possible to successfully appeal speeding tickets on Federal Highways on the basis of the combination of these engineering constraints and the Basic Speed Law, assuming no other road conditions made it unsafe. You can do the same thing for State Highways, but you have to be very careful, since it varies from state to state as to the requirements for a highway engineering survey (for example, in California, if one has not been performed in the 5 years preceeding a drop in a speed limit, you can get the ticket thrown).
So while there is no explicit loss of sovereignty, there is in fact a coercive loss of sovereignty to Federal authority.
-
As to your second statement, recklessness is a measure of degree of liability for an adverse result. Without an adverse result, there is no liability, and therefore no recklessness.
I think the situation you are talking about is more or less covered by laws against creating a public uisance (which is why those laws exist).
Personally, I consider it prosecutorial misconduct to file all the charges one possibly can construct a theory for filing against someone for a single violation or incident/crime, in the hopes that something will stick so you can "get the bastard".
As an example, "following too closely" is generally an add-on ticket that's thrown out there to make the initial ticket seem more worthy/severe; most states do not define in law what constitutes "too closely". The reason for this is that "too closely" is generally a matter of both the laws of physics, and the perceptions of the person being followed. There are rules of thumb, such as "two car lengths" (how many cubits in a car length?!?), which ignore rate of travel, and there are rules of tumb such as "the two second rule" (Utah statue without attached penalty) or "the two to three second rule" (DMV driver's handbook rule of thumb in California), but all of them have the problem that they ignore accelleration/decelleration of the following/followed car.
The only really valid codification would be a time interval or distance based on the following driver's measures reaction time, and differential speed and acceleration for the vehicles - a set of curves with a constant bias, which, if they crossed, would indicate a violation had taken place. You'd also have to take into account the followed driver's perception, which would resu
You could do that by getting a number of people employed at various fabs in an entry level position, and have them dump a bunch of powder with a moderate sublimation point in critical areas, and they could keep doing it until they started an investigation as to why chip yields had dropped to 1% of what they used to be.
Don't worry, I initially had the same question on 9/11, mainly "how could they be so stupidly ineffective in their choice of economic targets?".
But then I realized that terrorists are not interested in being effective in terms of traditional combat measures, other wise known as "kill ratio", or more generally, as "greatest military benefit for least cost".
Terrorism is no at all about military action; that's precisely why a "war on terror" is such a dumb idea.
PS: While we are at it, can someone pont me to the URL for the Library of Congress archive for the Articles of War ratified by Congress that made the "war on terror" an actual war, rather than a global exeditionary police action?
PPS: Can someone also tell me what the victory conditions are? I.e. will it be when we parade terrorisms body through the streets of New York on a post and throw it on a bonfire in Central Park?
The GP poster is correct; your examples (mostly *) are all actual incidents of a public safety issue; the GP's examples are all examples of enforcement of a rule already enforced by the situation:
- reckless driving: thought crime, ticket them only if they have an accident
- putting $1.50 in a broken meter: thought crime, ticket them only if they exceed the amount of time $1.50 would have bought them
- failing to signal in a turn-only lane: thought crime, ticket them only if the *don't* turn
* speeding is relatively arbitrary; what consitutes a safe speed depends on the road conditions, the engineering specifications for the roadway and vehicle, and the ability of the driver. This is why there is a "basic speed law", and why Interstate highways have different rules than state highways (hint: the state is not permitted to regulate what constitutes a safe speed on a federal roadway).
Most tickets these days are about revenue collection. Those that aren't are based on the _perception_ of public safety, which is based primarily on the visibility of the officers to the public.
This is why, in dense metropoliton areas, such as the Bay Area, you rarely see people pulled over for "fixit tickets" on expired registration/no registration/broken lights/cracked windshields/bald tires/failure to signal before lane change/etc. - low revenue tickets which, with the exception of the first two, are in fact public safety related.
I'm facetiously waiting for them to paint "This side towards enemy" on the customer side of the desks at the DMV...
-- Terry
It's not a single pet feature, it's an example
on
The Wii's Brain Exposed
·
· Score: 2, Interesting
It's not a single pet feature, it's an example.
If you want a laundry list, I can provide one, but we can start with this small list of things, which were also true of the i386 as well, making the current CPUs hopped up 386s:
o Too few general purpose registers (this one's glaringly obvious, and compared to dumping another 2M of cache onto a chip, it's relatively easy to fix, but it's only been partially fixed in the 64 bit implementations, and there it was more or less a matter of maintaining binary compatibility with AMD, who beat Intel to the punch)
o No TLB tags to support cache coloring, TLB shootdown of only impacted pages, reduced TLB flush, reduced IPI's between CPUs (yes, 386 supported SMP, if you used external APICs), and, in general, make memory management easier for OS engineers
o Continued reliance on a single FSB for all MESI transactions, instead of a crossbar bus, like in the DEC Alpha, or a Hypertransport, like in the AMD, limits the number of cores you can add before bus contention diminishes the utility of adding another core; let it be said that AMD only got this right, IMO, because they inherited the Alpha chip design team
o Off-board MMU does not provide the ability to off-load memory page zeroing from the main CPU; this leads to higher power consumption in your idle loop, if you zero pages there, and higher latency for clean pages, if you don't. It is *mandatory* to zeero pages before providing them for most uses, as a security issue; if it's just thee eating my electrons, waiting to be asked for pages, it should be *doing* something to earn its keep
o No hardware random number generators;/dev/random in Linux, BSD, et. al. is an Abomination Before God, mostly because there is no real hardware generator backing it, and so none of your interrupt processing gets done in bounded time because it "harvests entropy" during interrupt processing and other critical tasks
o Bad support for high resolution timers; in general, you have to jump through incredible hoops to get real HRT support in the hardware (unlike PPC or SPARC hardware), which end up taking a lot more work then necessary, since you have to mux them
o No vector MMU; SSE is very poor compared to a real vector processor; Altivec on PPC, vector on SPARC, and Weitek (from waaaay back when) all do much better on floating point; even if they didn't, non-compliance with IEEE-754 makes much of SSE a non-starter ("I can make it as fast as you want, if it doesn't have to be correct" - Ed Lane)
o No routing interrupts based on power management when routing is done in Intel MP Spec. "Virtual Wire" model; heck, no decent specific routing anyway (load based, and/or using source quench to implement LRP or other techniques)...let's start with those.
-- Terry
Call me when I can turn off in-order writes
on
The Wii's Brain Exposed
·
· Score: 2, Interesting
Call me when I can turn off in-order writes, and they provide barrier instructions so I can control the ordering from software so hyperthreading becomes more than something the P4 engineers thought of as a "compiler problem", without understanding that you don't *ever* run a single compiler-optimized instruction stream to completion without a context switch in a modern OS. You can optimize the non-interrupt code paths in the OS itself, but for apps running *ont top* of the OS, there is no such thing as a "non-interrupt code path"
The _only_ reason this hasn't been done is to maintain binary compatibility, which could be done by making it an MSR controlled option defaulting to "off for DOS & Windows compatiblity". Of course, then people like Linux, BSD, etc. would start taking advantage of it, and, well, kicking some serious butt.
Yeah, I agree with the GP, and I can point to a lot of other "features" of the hardware that make it a "supercharged 386", which, if they were turn-offable, would make the chips have *much* better performance, particularly with a lot of cores.
Sorry to contradict you, but the DEC Alpha supported 4 privilege modes, and they were used extensively by OpenVMS; it would not have been possible to port VMS to the Alpha architecture without them:
o User mode - User programs, compilers, editors, linkers, etc. o Supervisor mode - Command language interpreters o Executive mode - Privilege management o Kernel mode - The kernel
These are primarily used to protect stack regions so that, for example, the system can call ASTs back in user space on completion of system calls. See the "OpenVMS HACK FAQ" for more information on why stack smashing attacks don't result in escalated privilege on OpenVMS.
If you measure it as "payback of the purchase price", it could be as little as 2.5 years, depending on the specific technology.
If you measure it as ERoEI, it's generally acknowledged by everyone except die-hard solar power advocates that the ratio of Energy Returned over Energy Input for solar is less than 1, unless you use very very recent strained Silicon-based technology, which barely hit break-even earlier this year.
If you use thin film technology the purchase price payback grows to 4 years, and the Payback ERoEI drops to about 0.8.
There's also the little problem of there being a shortage of polycrystaline Silicon, from which solar cells are made. This shortage is expected to last through at least 2008, since it takes about 3 years to build a manufacturing plant for it, and that's what would have to happen to reduce the cost overhead.
So for right now, any decision to switch to solar by Google is going to be an economic one, rather than an environmental one.
Since Nanosolar is a thin-film photovoltaic shop, we are looking at a longer economic payback time; their output capacity after their plant is built will be 430MW of cells per year, so this will eaither be the first run cells, or it will be about a day and a half of cell output at their full production capacity.
FWIW, the 1.6MW capacity is going to put them at ~1/500th of the total US Solar capacity, which as of this year is at 927MW, for just this one installation. Comparatively, total US solar capacity is only 85% of the output of one of the two reactors at Diablo Canyon (1087MW each), while total US wind power capacity is 10,000MW and growing by 3,000MW in 2006 alone, according th AWEA (the American Wind Energy Association).
Slashdot Mirror
All job interviews require sales skills.
Even if you are not asking for a position in sales, you are selling a product: yourself.
There are two things any company is looking for:
o The ability to fulfill the requiremetns of the position
o Team fit
The first can be satisfied by work experience and paper credentials, if you have them. Depending on your ability to sell yourself as being able to do the job - your reputation in the field of endeavor (if you have one), your paper credentials coming from a place with a reputation in the field, your paper credentials with regard to union and other organization membership with a reputation in the field, and so on - you may or may not end up needing to have references that can be checked, letters of recommendation, and so on.
The second is a matter of personal prejudice, and whether or not you rub the person/people interviewing you the right way or the wrong way.
If you get to an interview, then your paper credentials, on face value, are sufficient that they expect that - if you did not lie about your capabilities in your resume or on the application - you can do the job. So the purpose of the interview is almost entirely (80%) a matter of determining whether or not the organization wants you, as a person, working there, and only a little bit (the remaining 20%) about whether or not you lied on your paperwork.
Your reference to "programming classes in high school" implies that you are either currently in high school, or a recent graduate, and either are not yet in college, or are recently enough enrolled that you can't point at classes from your college experience yet, instead.
No one is going to be impressed with your high school technical credentials, unless you went to a magnet school, attained some type of certification, or can demonstrate involvement in some level of professional project. Without that, having done well in a high scholl technical class merely means "attended class regularly, did not make a nuisance of themselves, turned in most of their homework, did not outright flunk tests".
If you are dying to demonstrate your "Mad Technical Skillz", take a job where there will be opportunity to demonstrate them, but for which they are not a requirement for the job you take. If you have them, and the place employs people like that as well, then your demonstration will be enough. Otherwise, consider going to college - your opinion of your "skillz" is probably higher in your mind than in reality.
In terms of getting the jobs that you've applied to - if you've genuinely applied to 12 fast food places, and not been hired at any of them, there's something wrong with _you_, in terms of employability. If you've genuinely applied to 27 total places, and only been interviewed twice, then the problem is likely your appearance - cleanliness (breath, B.O.), behaviour, clothing, hair style, piercings, tattoos, or something similar. All of these are part of being able to sell yourself to an employer, and all of these would have either nixed an interview happening in the first place, or if you escaped the screening process, sunk your interview immediately.
In addition, there could be other factors; if you are currently in high school, or graduated early, you could legally be too young to work. If you've indicated that you are going to college out of state, and this is "just a summer job", then you are a fly-by-night employee, who will get trained enough to be worth your wage, and just as you become useful, are expected to take off for parts unknown.
Frankly, even if you are in high school, but old enough to legally work (17+), it's not that hard to get an entry level job. You just have to sell yourself.
A shower, dress slacks, a casual shirt, socks without holes, normal shoes (not motorcycle boots with 2 pounds of metal with scrollwork on it), etc. indicate to your potential employer that you take the opportunity to work for them seriously, and that you're willing to dress up to attt
Bounded time, malloc, new, using GC in a project..
Actually, you can run a malloc or a new in bounded time; the issue is whether or not you have an allocator that's capable of doing it or not. If you preallocate objects to your zone, you can perform the operation in O(1) - the amount of time to take something off the free list - and you can do it without locking, so long as you utilize per-CPU pools for your object freelists. If you want to grab one and the freelist is empty, you can fail the operation and force it to retry later (or you can decide not to reenable interrupts until the top end has completed processing and returned the free work item to the interrupt handler one-item-pre-cache).
My personal preference would be to preallocate as much as I will need to run the operation to completion - and no more. It's OK to have a data source that's noisy and generates a lot of work items, but only if it happens at soft interrupt.
For things like network drivers, the delyed reenabling of interrupts is the best bet. First of all, you likely want to take one interrupt and poll like hell until there's no more data; an 8MHz PC can keep up with 115K baud serial data (barely) if you do that, whereas direct interrupt processing will cause it to lose it. Second, you don't want to reenable the interrupt to let it reinterrupt you if you can't drive the data all the way to the application anyway; reenabling the interrupts prematurely leads to problems like receiver livelock, which has been known about for years (google for "livelock" "networking" "DEC" "WRL" "Jeff Mogul").
As far as using GC in a project, I've done it, and I've seen it done (Objective C supports GC in the next release of Mac OS X, as reported on Apple's web pages, so I'm not letting any cats out of any bags). My personal opinion is that once one framework you need becomes "GC-only", there will be no way to make code that correctly operates as both GC and non-GC code. The problem is that programmers are human, and they make mistakes, and if the mistake happens to be that you forget to release some memory, but it's OK because GC catches it, then you will never be able to go to a non-GC world and depend on that code again. For me, that means I can never take that code, or a part of it, and put it into an environment where GC isn't possible because I need to run in bounded time, without debugging it, or doing a full branch path analysis on it and generating test cases to exercise all the code paths; at that level of cost, I might as well just rewrite it from scratch.
A real world example of this was the use of the TSM (Tivoli Storage Manager) Java edition on the Whistle/IBM InterJet (I worked at Whistle, which was acquired by IBM). The TSM had an insane memory footprint, and we never shipped it as a product. While the GC in the Kaffe JVM kept the footprint to about 1/3 of the memory that the Sun JVM's GC did at the time, that was still twice the amount of physical RAM we had budgeted for the box. This was all user space code, but driving up the COGS of a product by 11% on the off chance that we would be able to later sell a service add-on for TSM to a percentage of the people who bought the product on its own merits was just bad business.
-- Terry
The difference between 1 & 2 as you've posited them:
1. Allocating objects on the interrupt handler's stack.
2. Allocating objects in a zone that is reserved for the interrupt handler.
is that in the second case you could suffer from zone exhaustion, and be unable to refill the zone at interrupt time. This may occur because there are no pages available, or because refilling the zone would block, or because the zone of zones is exhausted.
If you could override the allocation with an alloca() to force it back onto the stack, then this would not be an issue; however, the general reason for using zones is to obtain type-stable memory.
[Aside:]
You do this to prevent someone else's double frees or use after free from shooting you in the foot: you are guaranteed that the damage will be scoped to the zone, and therefore limited to the object type in the zone. So as long as you are not talking about generic sized zones (i.e. zone allocators typically implement a set of "powers of two" zones for random, temporary allocations), then any problem you have can be located relatively easily, since it's scoped to a fairly small amount of code.
[/Aside]
I don't think, therefore, that it's really going to end up very useful to map a zone to an alloca() in the general case, since you might as well use stack declaration or alloca() directly; the exception to this would be object scoped languages (e.g. like the one we are discussing here), to permit abusing the override for a subclass of the object acting as the object type (this would probably be considered "bad form", from my reading about the language).
Hope that clarifies what I said a bit...
-- Terry
I have a problem with GC in a systems language... specifically, using GC means that your functions will not necessarily run in bounded time.
For a lot of uses, particularly in user space, this is not a problem, but if you were to kick of GC in an interrupt handler or trap handler, or a number of other places, this would make it impossible for you to implement code that was guaranteed to take at most a maximum number of CPU cycles.
The upshot of this is that so long as it's possible for someone to write a driver that ends up running in your kernel, and which depends on GC functionality to not leak memory, it will be impossible for an OS written in that language to support hard real time.
I have to say that GC is marginally useful for systems work only if you can run it on a system that doesn't need GC -- so that you can get a read out of where and how you are leaking memory, fix the problem, and then disable GC before you ship. In other words, it's a great diagnostic, but only if you can run both GC and non-GC at the same time, and only if you explicitly scope your allocations (i.e. act like you are not running in a GC'e lanuage in the first place).
In other words, the intent of GC is to make programmers not have to know where their scope boundaries are, and you _must_ know this for systems programming tasks. So it doesn't deliver on its promise in a systems context, though it could be a helpful diagnostic for developers.
-- Terry
The primary reason for stack class allocation is that you may need to do your instancing at interrupt time or in a trap handler.
Consider the case where you have a memory shortage (but interrupt stacks are preallocated, per interrupt), and therefore you cannot do an allocation, but want to run the current operation to completion.
Consider also the case where you might be using a zone allocator, and you cannot expand the zone of zones, because in order to do so, you' need to handle a trap at ring 0 in a trap handler (i.e. a user page fault followed by a kernel page fault).
The reason that these things wuld not be allocable at interrupt/trap time is that the allocations may block, and, if they do so, you could effectively end up blocked with interrupts disabled and no way to get back from it.
The alterantive to this is that you would have to fail the request and back out your state all the way back (fail gracefully out). The problem with that approach is that now you have to put error checking around all of your function call graph hat could eventually result in potentially failing allocations, and deal with the performance degradation that might result (speculative execution on a PPC would make this effectively free, but on an x86, you would pay a fairly seiors penalty).
There are three approaches commonly used in handling memory stavation situations:
(1) Block until the memory is available
(2) Fail the allocation request, and be prepared to deal with the failure, and then hope that by backing off, you don't lose unrecoverable state (e.g. if I read a hardware register, that might signal something to the hardware that would preclude me restarting the operation - for example, the AMD Lance Ethernet hardware), and that it's possible to redrive the operation
(3) Djikstra's Banker's Algorithm: allocate all resources that you might need up front, before attempting the operation (this is typically what's done with, e.g. the ring buffers associate with ethernet devices, rather than allocating mbufs at interrupt level).
The instancing of classes on the stack falls under a variant of #3: because you already have the stack preallocated, you are guaranteed that, so long as you do not exceed your stack depth, instancing the objects you need to instance for the lifetime of the transaction you are about to perform will always be successful.
I'm not sure if that's the argument the poster to whom you were replying was referring, but I hope that clarifies things for you.
-- Terry
"Can someone please explain to me what the market is for portable video players with builtin viewing screens, in general?"
Glad to... you can't see video on a portable video player without a viewing screen. Hence the desire for a viewing screen.
Hope that helps you out, there.
Cheers,
-- Terry
Vista is not as innovative as you think...
"Windows Vista is the only one that has a protected kernel space, encrypted memory, and randomized memory locations, keeping the user locked away from their hardware."
I. All modern OSs that run on hardware capable of it have a protected kernel space. Mac OS X has been protected mode from Day one, and BSD and Linux (with the exception of intentional ports to poor hardware, like Palm pilots) have had it since day one (1991 for Linux, 1978 for BSD).
II. Encrypted memory is not that useful, without an embedded MMU to do the encryption. The XBox 360 has this, but common Intel hardware does not. Mac OS X has supported encrypted swap and disk images for several years now, and it's common enough in CS circles to experiment with this stuff, so BSD and Linux have spported it as well. As far as code or data are concerned, without the MMU built into the chip, there's no hope of preventing other software running on the system from simply reading the information themselves, either out of plaintext pages, or out of the CPU cache itself.
Either way, encrypted memory does approximately diddly for increasing actual machine security.
III. The randomization of memory locations in Windows is intended to prevent use of a known address for functional OS routines by exploit code that is already running on the system. In other words, its intent is to simply take away access to library routines. The obvious counter to this is to not use he OS routines, and simply carry around your own. The base assumptions here are that:
(1) The attacker has successfully caused code to rune
(2) The code is running in ring 0, having already defeated everything intended to prevent it getting there
(3) The code will call system subroutines to perform work, rather than carring around its own code for e.g. strcpy()
Carry around your own code to do this work, and the target machine is just as screwed; so I'd say that all they've done is increase the size of malware, not eliminate it.
Face it: the only way to make a machine completely secure while leaving it operational is to go locked down from boot onward, and down that road lies "trusted computing", with its own ability to be abused to take rights away from the owner of the machine.
-- Terry
It was Andrew Tridgell, not Jeremy Allison who founded Samba.
Jeremy has been an amazingly important contributor to the project, but it was Andrew's "AT&T LANMan compatibility code" that started the project .
I know, because I brow-beat Andrew on Usenet until he released it after mentioning it once in a post to one of the news groups, and once it was released, I suggested that he start a mailing list for it (we had a bunch of AT&T WGS boxes that AT&T had donated to the University, they all had LANMan, and I wanted to hook them up to the Ultrix box we had).
Also, I used to work in the cublicle across from Jeremy when he was working at Whistle communications before it was bought by IBM. 8-)
-- Terry
They DO have responsibilities, and ARE punishable.
Punishments include fines, sanctions, and so on - up to and including breaking them up and/or revoking their articles of incorporation.
For example, Western Electric was prohibited from competing for profit in the computer software market (the original availability of the UNIX operating system source code was as a direct result of this, as were the license terms that resuled in Berkeley UNIX and the Lyons book out of the University of New South Wales).
For other crimes, coprorations can be held responsible in the persons of their corporate officers, just as HP is currently being held accountable for obtaining the same information about a number of its board members and news reporters.
The example of the PG&E poisoning the groundwater with Chromium in Hinkley, CA (a small town near Barstow, CA), settling for $333M to 650 plaintiffs (the basis of the movie "Erin Brockovich"), and again in 2006 to another 1,1000 plaintiffs in other rural areas is another good example.
It's very rare for a corporation to have its articles of incorporation revoked However, breakups can and do occur; the A&T breakup was a court ordered punative action under the Sherman Antitrust Acts for the illegal use of monopolistic powers.
The entire point of Microsoft fighting the DOJ in the action that resulted in them being declared a monopoly under the law was to avoid such punative action.
I don't have a ready example of a total disassembly of a corporation, but "the death penalty" is available as a punishment, and is technically capable of being applied by the secretary of state in the state in which the company is incorporated. This would most likely that the form of an action brought by the state attorneys general of that state, resulting in a court order to that effect.
-- Terry
I wasn't going to post in this "discussion", mostly because the original question is blatanly biased, and assumes a particular position is held by the reader, and then asks them to explain it... "So, sir, what would it take to get you to stop eating children?".
However, you're such a blatant appologist that I have to say something.
A corporation is called a "corporation" - and has been "incorporated" - because it has been "given a body" under the law to operate on behalf of a group of persons, and has certain rights AND RESPONSIBILITIES, just as any member of society.
The idea that a company, or its officiers, should put fiduciary responsibility on a pedestal, far above any other responsibilities to the society that permitted its incorporatinon, and on whose sufferance its continued existance depends, is relatively recent. Adherence to a specific duty above all other duties or considerations is the moral equivalent of the "Nuremberg Defense".
If a person can sell their soul, and if a corporation is a person under the law, then surely there are also many recent examples of corporations selling their souls.
-- Terry
For eln's delecate sensibilities about perl...
echo "this is a sentence" | awk '{ cnt = NF; while ( cnt > 0 ) { printf( "%s ", $cnt ); --cnt; } printf("\n"); }'
Happier?
-- Terry
When everyone has one, what's the point of stealing one? Who are you going to sell it to?
Your biggest market would be eBay'ing it to nerds who want to write software for it, because of it's general unavailability in first world countries. This option immediately goes away as soon as they ram production and start providing them for higher (but still low) cost to developers who want one to hack code on/play with.
Or to put it in Monty Python terms:
-- Terry
Off topic, but...
The primary reason AI is seen as unsuccessful is because as soon as some aspect of the problem has been solved and the code works, we rename it to something else: speech synthesis, speech recognition, character recognition, motion capture, genetic algorithms, neural nets, edge finding, adaptive control systems, fuzzy logic, etc. etc..
AI research has been very successful, in general, but in specific it has about as much chance as being recognized as successful as a nuclear power plant has of completing construction under the same regulations environment it was designed in, or a four year lame duck president seeing his "five year plan" followed through to completion.
-- Terry
"we've never paid administrators & teachers so much ... and gotten so little"
... and gotten so little"
Corollary: "We've never paid CEOs & janitors of major corporations so much
If you think all the tax money being collected "for education" is going to my aunt, a special needs teacher in a moderately run-down school district, or went to my grandmother when she was a public school teacher, I have a used bridge to sell you. Low mileage, one owner, only driven on Sundays.
The money never goes to the line workers, I don't care what business you are talking about.
-- Terry
The big benefits of college (assuming you apply yourself) are:
...my faculty advisor was adamant in calling 4 year degrees "union cards". After more than 20 years in th
(1) You lean how to think
Most people don't know how to think; they don't know how to think about solving problems, minimally, or, worse, they actually don't know how to think logically at all.
In college, you can fix the second by taking logic, philosopy, criminal law, mathematics, and other clasess.
The only classes I've seen be effective at fixing the second are hard science classes, particularly physics, but also electrical engineering, and some types of chemistry. Other classes can help, but the softer the science, the less likely there is to be a single correct answer to a question, so the less likely you are to hone your skills at getting from the question to the answer. Physics tends to be particularly good, since you start with the answer you intuit, and then come up with questions to determine whether or not the answer is right - this builds both your reasoning/critical thinking skills and your intuition.
(2) You learn the terminology necessary to talk to peers in a technical field
I work as core kernel engineer for the second largest OS company on the planet. There are maybe two dozen of us at this level, depending on how widely you interpret the team.
There are people who would be involved in your interview process here which, if you couldn't use/regcognize proper terminology for even trivial data structures (what's a B-tree, what's a splay tree, what's a trie, what's a skiplist, what's a doubly linked list, etc.) would be happy to walk you to the door. And that's just getting your feet wet in the interview.
Yes, it's possible to pick some/most of this up by being an apprentice somewhere, but doing that, you're going to get local jargon as well, and you aren't going to be able to distinguish it from the real thing, which is going to make you hard to talk to about complex problems. This factors into your team fit (which is ~80% of getting hired, if you haven't lied on your resume, and you got an interview in the first place).
(3) You learn different ways to solve the same problem
One of my favorite interview situations is to ask someone how they've solved a particularly difficult problem in the past, and then poke at it to see if they've been able to come up with some other ways to solve the problem than I did, just thinking about it from their explanation of things. If I can come up with a dozen ways to solve the same problem, and they can't justify why they didn't think of them, or why those approaches would have been less optimal, I'm not very impressed.
You aren't going to get the ability to do this without either a lot of experience, or the exposure to different teaching approaches and approaches of different teachers to solving problems. You can build this over a large number of years of experience, or you can bootstrap your thinking by going to college (and applying yourself).
(4) You establish contacts with people you will meet again and again throughout your life
Do not understimate the value of this. My first job in my college career was a workstudy job. My next job was a lab aide, helping other people solve their problems (or, more generally, helping them arrive at a workable solution on their own). My next job was a series of contract jobs outside the college, for a person I'd met there (also a student), with a less technical and more business bent. I had other work-stuudy jobs, and I did some introductory lectures on various things like how to use the editors, etc.), but my first post-college job was at a company that was owned by a friend of one of the procefessors there.
Never, never, underestimate the value of the contacts you will make, and the personal network you will build, while going to college.
(5) And even if you only apply yourself enough to get the certificate... you get your union card
As a prelude to this, let me state that I obey the posted speed limits.
-
Eisenhower in fact nationalized the highway system; however, that was not my point.
A previous poster in this thread correctly identified my point, which is that the Federal government uses coercive tactics- specifically, the threat to withold distributing Highway funds collected from the states to a particular state, if some subset of laws in a given set of laws is not passed within the state. On top of this, there's a compact between the states called "The Driver's License Compact", in which the states are legally bound to normalize laws between member states as much as possible. So you get things like a motorcycle helmet law in all compact stats, or a uniform speed limit.
Now in the nationalization process in the 1950's, there were a number of things which happened simultaneously; one was the standardization of lane widths, weight capacity, and overpass clearances for "Mobile Nuclear Command Posts" to be able to tracvel to anywhere in the U.S. over the Federal Highway Sytem. Another was engineering minimum speed capability for the Federal Highways: all such highways are required to support vehicles moving *at least* a minimum set speed (initially, 60 MPH) to control maximum time from incident to response, so there are engineering requirements on grade on curves, lengths of curves, bridge carrying capacity, etc., etc., for Federal Highways. At the same time, a funding requirement for a state law was imposed called the "Basic Speed Law" (that's it's name in California, Montanna, and Utah; other states call it other titles).
It's actually possible to successfully appeal speeding tickets on Federal Highways on the basis of the combination of these engineering constraints and the Basic Speed Law, assuming no other road conditions made it unsafe. You can do the same thing for State Highways, but you have to be very careful, since it varies from state to state as to the requirements for a highway engineering survey (for example, in California, if one has not been performed in the 5 years preceeding a drop in a speed limit, you can get the ticket thrown).
So while there is no explicit loss of sovereignty, there is in fact a coercive loss of sovereignty to Federal authority.
-
As to your second statement, recklessness is a measure of degree of liability for an adverse result. Without an adverse result, there is no liability, and therefore no recklessness.
I think the situation you are talking about is more or less covered by laws against creating a public uisance (which is why those laws exist).
Personally, I consider it prosecutorial misconduct to file all the charges one possibly can construct a theory for filing against someone for a single violation or incident/crime, in the hopes that something will stick so you can "get the bastard".
As an example, "following too closely" is generally an add-on ticket that's thrown out there to make the initial ticket seem more worthy/severe; most states do not define in law what constitutes "too closely". The reason for this is that "too closely" is generally a matter of both the laws of physics, and the perceptions of the person being followed. There are rules of thumb, such as "two car lengths" (how many cubits in a car length?!?), which ignore rate of travel, and there are rules of tumb such as "the two second rule" (Utah statue without attached penalty) or "the two to three second rule" (DMV driver's handbook rule of thumb in California), but all of them have the problem that they ignore accelleration/decelleration of the following/followed car.
The only really valid codification would be a time interval or distance based on the following driver's measures reaction time, and differential speed and acceleration for the vehicles - a set of curves with a constant bias, which, if they crossed, would indicate a violation had taken place. You'd also have to take into account the followed driver's perception, which would resu
Then ticket them, obviously, assuming you catch them; most likely, you will be concentrating on the victims, instead.
-- Terry
You mean like these people hired to write them?
l ?articleID=163702855
http://informationweek.com/story/showArticle.jhtm
-- Terry
Contaminate some chip fabs?
You could do that by getting a number of people employed at various fabs in an entry level position, and have them dump a bunch of powder with a moderate sublimation point in critical areas, and they could keep doing it until they started an investigation as to why chip yields had dropped to 1% of what they used to be.
Don't worry, I initially had the same question on 9/11, mainly "how could they be so stupidly ineffective in their choice of economic targets?".
But then I realized that terrorists are not interested in being effective in terms of traditional combat measures, other wise known as "kill ratio", or more generally, as "greatest military benefit for least cost".
Terrorism is no at all about military action; that's precisely why a "war on terror" is such a dumb idea.
PS: While we are at it, can someone pont me to the URL for the Library of Congress archive for the Articles of War ratified by Congress that made the "war on terror" an actual war, rather than a global exeditionary police action?
PPS: Can someone also tell me what the victory conditions are? I.e. will it be when we parade terrorisms body through the streets of New York on a post and throw it on a bonfire in Central Park?
Thanks,
-- Terry
The GP poster is correct; your examples (mostly *) are all actual incidents of a public safety issue; the GP's examples are all examples of enforcement of a rule already enforced by the situation:
- reckless driving: thought crime, ticket them only if they have an accident
- putting $1.50 in a broken meter: thought crime, ticket them only if they exceed the amount of time $1.50 would have bought them
- failing to signal in a turn-only lane: thought crime, ticket them only if the *don't* turn
* speeding is relatively arbitrary; what consitutes a safe speed depends on the road conditions, the engineering specifications for the roadway and vehicle, and the ability of the driver. This is why there is a "basic speed law", and why Interstate highways have different rules than state highways (hint: the state is not permitted to regulate what constitutes a safe speed on a federal roadway).
Most tickets these days are about revenue collection. Those that aren't are based on the _perception_ of public safety, which is based primarily on the visibility of the officers to the public.
This is why, in dense metropoliton areas, such as the Bay Area, you rarely see people pulled over for "fixit tickets" on expired registration/no registration/broken lights/cracked windshields/bald tires/failure to signal before lane change/etc. - low revenue tickets which, with the exception of the first two, are in fact public safety related.
I'm facetiously waiting for them to paint "This side towards enemy" on the customer side of the desks at the DMV...
-- Terry
It's not a single pet feature, it's an example.
/dev/random in Linux, BSD, et. al. is an Abomination Before God, mostly because there is no real hardware generator backing it, and so none of your interrupt processing gets done in bounded time because it "harvests entropy" during interrupt processing and other critical tasks
...let's start with those.
If you want a laundry list, I can provide one, but we can start with this small list of things, which were also true of the i386 as well, making the current CPUs hopped up 386s:
o Too few general purpose registers (this one's glaringly obvious, and compared to dumping another 2M of cache onto a chip, it's relatively easy to fix, but it's only been partially fixed in the 64 bit implementations, and there it was more or less a matter of maintaining binary compatibility with AMD, who beat Intel to the punch)
o No TLB tags to support cache coloring, TLB shootdown of only impacted pages, reduced TLB flush, reduced IPI's between CPUs (yes, 386 supported SMP, if you used external APICs), and, in general, make memory management easier for OS engineers
o Continued reliance on a single FSB for all MESI transactions, instead of a crossbar bus, like in the DEC Alpha, or a Hypertransport, like in the AMD, limits the number of cores you can add before bus contention diminishes the utility of adding another core; let it be said that AMD only got this right, IMO, because they inherited the Alpha chip design team
o Off-board MMU does not provide the ability to off-load memory page zeroing from the main CPU; this leads to higher power consumption in your idle loop, if you zero pages there, and higher latency for clean pages, if you don't. It is *mandatory* to zeero pages before providing them for most uses, as a security issue; if it's just thee eating my electrons, waiting to be asked for pages, it should be *doing* something to earn its keep
o No hardware random number generators;
o Bad support for high resolution timers; in general, you have to jump through incredible hoops to get real HRT support in the hardware (unlike PPC or SPARC hardware), which end up taking a lot more work then necessary, since you have to mux them
o No vector MMU; SSE is very poor compared to a real vector processor; Altivec on PPC, vector on SPARC, and Weitek (from waaaay back when) all do much better on floating point; even if they didn't, non-compliance with IEEE-754 makes much of SSE a non-starter ("I can make it as fast as you want, if it doesn't have to be correct" - Ed Lane)
o No routing interrupts based on power management when routing is done in Intel MP Spec. "Virtual Wire" model; heck, no decent specific routing anyway (load based, and/or using source quench to implement LRP or other techniques)
-- Terry
Call me when I can turn off in-order writes, and they provide barrier instructions so I can control the ordering from software so hyperthreading becomes more than something the P4 engineers thought of as a "compiler problem", without understanding that you don't *ever* run a single compiler-optimized instruction stream to completion without a context switch in a modern OS. You can optimize the non-interrupt code paths in the OS itself, but for apps running *ont top* of the OS, there is no such thing as a "non-interrupt code path"
The _only_ reason this hasn't been done is to maintain binary compatibility, which could be done by making it an MSR controlled option defaulting to "off for DOS & Windows compatiblity". Of course, then people like Linux, BSD, etc. would start taking advantage of it, and, well, kicking some serious butt.
Yeah, I agree with the GP, and I can point to a lot of other "features" of the hardware that make it a "supercharged 386", which, if they were turn-offable, would make the chips have *much* better performance, particularly with a lot of cores.
-- Terry
I was paraphrasing the 21164 reference manual there... FWIW. You can download it from:
c tor/literature/dsc-library.html
http://ftp.digital.com/pub/Digital/info/semicondu
-- Terry
Alpha supported 4 privilege modes
Sorry to contradict you, but the DEC Alpha supported 4 privilege modes, and they were used extensively by OpenVMS; it would not have been possible to port VMS to the Alpha architecture without them:
o User mode - User programs, compilers, editors, linkers, etc.
o Supervisor mode - Command language interpreters
o Executive mode - Privilege management
o Kernel mode - The kernel
These are primarily used to protect stack regions so that, for example, the system can call ASTs back in user space on completion of system calls. See the "OpenVMS HACK FAQ" for more information on why stack smashing attacks don't result in escalated privilege on OpenVMS.
-- Terry
Payback depends on how you measure it.
0 25&ch=biztech; they provided the initial seed funding, according to a release on Nanosolar's web site: http://www.nanosolar.com/pr5-6.htm (see second release at this page).
If you measure it as "payback of the purchase price", it could be as little as 2.5 years, depending on the specific technology.
If you measure it as ERoEI, it's generally acknowledged by everyone except die-hard solar power advocates that the ratio of Energy Returned over Energy Input for solar is less than 1, unless you use very very recent strained Silicon-based technology, which barely hit break-even earlier this year.
If you use thin film technology the purchase price payback grows to 4 years, and the Payback ERoEI drops to about 0.8.
There's also the little problem of there being a shortage of polycrystaline Silicon, from which solar cells are made. This shortage is expected to last through at least 2008, since it takes about 3 years to build a manufacturing plant for it, and that's what would have to happen to reduce the cost overhead.
So for right now, any decision to switch to solar by Google is going to be an economic one, rather than an environmental one.
This makes sense, since Larry Page and Sergey Brin are invested in a Solar power startup, Nanosolar http://www.techreview.com/read_article.aspx?id=17
Since Nanosolar is a thin-film photovoltaic shop, we are looking at a longer economic payback time; their output capacity after their plant is built will be 430MW of cells per year, so this will eaither be the first run cells, or it will be about a day and a half of cell output at their full production capacity.
FWIW, the 1.6MW capacity is going to put them at ~1/500th of the total US Solar capacity, which as of this year is at 927MW, for just this one installation. Comparatively, total US solar capacity is only 85% of the output of one of the two reactors at Diablo Canyon (1087MW each), while total US wind power capacity is 10,000MW and growing by 3,000MW in 2006 alone, according th AWEA (the American Wind Energy Association).
-- Terry