I've seen you before. You are basically stuck in a box. (the box of your preconceptions and way of thinking) That box is pretty closely related to the 'union thug' box, not to put too fine a point on it. That box pretty well destroyed Detroit over a period of 40 years. That box will prevent you from ever succeeding beyond a low level, unless you change jobs, get an MBA and go to work for the next group of Wall Street sociopaths (no, not all WS folks are sociopaths, but they're always out there - a separate topic).
When you take a job, you are providing a service in return for pay. This is a standard bargain, just like when you get a haircut. The barber offers a service, and you pay the barber. If the barber gives you an attitude, or doesn't do a good enough job, you will go somewhere else next time. If he/she does a real crap job or pisses you off enough, you won't pay him. But if he does a very good job, has a good attitude and goes above the standard, you might tip him extra.
Similarly, if you do a bit above the standard, look for how to make the company succeed, at most (not all) companies you are likely to be noticed, and sooner or later are more likely to be promoted, given a raise, or in bad times, less likely to be laid off. Sure, some companies don't follow that model - but even then, if you have done the right thing, at least _some_ of the folks in almost any company will be available to give you a good reference when you go somewhere else. So it's just good marketing unless you're a scam artist.
I used to work in the oil exploration business. There are about 30,000 oilfield engineers in the world. It's essentially a small town. If a field engineer made a mistake, that was usually not fatal. But if an engineer screwed somebody over, or failed to carry through on a promise, everybody in the business knew about it soon enough. If that happened enough times, that engineer would eventually be unable to get a job anywhere in the business - or would end up working from some scab outfit working with old crap equipment and cutting corners wherever they could.
Just so you know, the above is not a fantasy. It's exactly how things have worked for me, most places, most times, through a 40 year career. Because I always tried to do the best for the company, even when things didn't work out, I could honestly tell potential employers what I did do, what didn't work out, and why. And I never got negative feedback as a result. Potential employers can smell a rat, and unless they are rats as well, prefer not to hire them.
Me too. I've fired, and seen fired, people who were too 'effective' at making themselves the single point of failure. Usually they were also irritating, whiny SOBs who had a talent for sabotaging others' work.
Conversely, while I'm naturally an introvert and work best on my own, in my present job I've been very successful at using my own efforts to include others in my projects. It's improved my work, it's improved the stability of part of the IT universe that I'm involved in (many people know at least something about my work), it's improved my position in the company. I'm almost certainly considered more 'necessary' as a result. I suppose this could be considered 'dynamic necessity' as opposed to 'static necessity' where 'static necessity' means, more-or-less, "he's the only one who knows how that POS program works."
By putting my own work into a Mercurial repository, using dotProject and Trac to manage my own one-man projects and encouraging code reviews and release management of my projects into production IT, the others in this small company were gradually introduced to more-or-less modern project practices, and essentially had to get used to using these tools in order to integrate my work into the production environment. At first only a fraction of that group were interested, but now this has succeeded to the extent that the entire IT staff is now adopting essentially the system that I and the others in my group have been using. In the process, several other people have at least reading knowledge of how my code works, and how it fits into the bigger systems. And that integration process is now documented reasonably well so others can figure it out later.
(One clue - the Trac wiki makes a natural place to make notes while one is figuring out how to build a system, and in the process. Those notes are easy to convert into formal docs later. So those weird little facts and real-world idiosyncracies that affect how the code works are documented both in the code, and in the wiki.)
Hmm. Fortunately most of us boomers were too stupid to save any money, so they can't afford to retire for another 10 or 20 years. That should actually help out SS.
A majority of sites that I go to (especially news sites) do not work correctly unless both cookies and javascript (at least _their_ javascript, plus maybe Google API, if not a bunch of third party javascript). And the pool of sources for that stuff that is required to make things work is expanding at a high rate. So one can not just block all cookies all the time. So one has to allow or disallow on a site-by-site basis. Installing the extensions (NoScript, Adblock, et al) is the easy part. After that it requires dealing with the NoScript options on almost every site. I do it, and it's helpful, but it's not trivial. A lot of sites use flash for video or slideshows or audio, that won't load unless you allow scripts at least temporarily. I'm not disagreeing, just whining. &_&
I listened to a keynote speech by a futurist at the 2001 O'Reilly Open Source Conference in Monterey California. He was talking about how existing technology would be used. Among other things, when you went to the mall face recognition systems (along with other stuff like wi-fi and bluetooth snooping) would attempt to figure out who you are. You would have HW that tries to prevent that by jamming or other means. Then as you walk down the entry hall, floating holographs would appear in front of you with sound only you can hear (sonic holography), saying "Ah, Mr. Doofus, welcome back. Two years ago you bought sneakers at Shoes-R-Us. Those are probably worn out. Shoes-R-Us is no longer here but Joe's Sneakers is offering you 20% off on all sneakers, just for you. Turn at the next corridor on the left. And that blouse your wife looked at two weeks ago at SuperMs is still available. Perhaps you'd like to get it for her birthday? SuperMs can give you 10% off just for today."
For myself, I'm gonna live in the woods, or on the ocean - far from any mall.
IOW, for GA we (our eyes) are the product, not the consumer.
I have had GA blocked in NoScript for a long time. I don't know if it has any real effect, of course. Maybe I'll check out the topic of this/. article just to see if it has any effect. I also blocked doubleclick.net permanently a long time ago after one too many pop-ups. I don't block everything either with NoScript or AdBlock, just those that are offensive, obtrusive and/or creepy. I feel that letting them show me ads is part of the bargain. But knowing the size of my underwear is not.
Boy, been there, done that, burned the t-shirt. As a VP R&D in a startup a long time ago (early 1990s) I once spent two months with my software manager doing a complete system plan for a complete rewrite, rearchitecture and platform change (including converting from several languages to C), down to the function level, with good estimates of the time it would take to do every piece of it. This was a product with several hundred thousand lines of code in FORTRAN, Pascal, Assembler of various sorts, maybe some C, and microcode for a custom image processor. It came down to six engineers and about two years. We got approval for that project plan at the board meeting.
Then one of the engineers mentioned to the head of sales that he thought we would 'have an image on the screen' (meaning we would have figured out how to write a toy/test program to paint a window) in about two months.
Within a few days, the sales guy had promised delivery of two systems in... you guessed it... two months, to GE. Oh, and by the way - the company didn't have the cash flow to hire more engineers, so we only had two guys available to the project. As it happened, I quit a week or so later for other reasons. According to what I was told later, by conspiring with the users at GE who agreed to receive the boxes, they managed to ship two completely non-functioning systems to GE, and spent the next two years 'fixing' it while the folks at GE got more and more pissed. I think GE finally sued them. After numerous equally dicey escapades, the company got forced into bankruptcy.
I think HP is in a different market than Apple. Apple's success is still mostly in the consumer space. HP has major market share in the corporate and business space, and is making noises about integrating WebOS on the PC with WebOS on the Touchpad and other devices. That market is less price sensitive, is two or three years behind the consumer market trends, considers performance less important than "works with SAP" - or QuickBooks, and is _very_ interested in working with a strong, big, reliable (if unsexy) company like HP.
So I think HP is going to own the corporate *pad business, but it will take three to five years.
Yes. Also, HP doesn't need consumers so much as business, where they sell most of their PCs. So I predict that there will be a lot of integration of WebOS on the PC to 'enterprise' apps like SAP, and extending that integration to the Touchpad to provide 'secure instant remote access' to the corporate data from anywhere. The larger form factor of a 'pad makes it a perfect growth path from the crackberries and things of that ilk. IMHO HP is better positioned for this market than anyone.
I don't think the 'late to market' question applies, as this market tends to lag the trendy consumer market by two or three years. So the present Touchpad can be a testbed for corporate developers to try WebOS apps out on their PCs and the Touchpad itself, and the next version makes those apps sing just in time for the volume buys. Look for SAP on the Touchpad.
Fast: They were late to market, with HP doing seemingly nothing for about a year. They're enormous, why didn't they hire more (or more likely, better) people if they couldn't iterate as fast as the competition.
I don't know the details of the innards of the platform software (scale or complexity) but the general rule is that adding more people - even 'better' ones - generally slows projects down and just burns money. It takes newbies to a platform a year or so to get to the point where they understand the architecture well enough to really do good work. It's possible that they spent the year just fixing architectural issues in the system, rather than painting lipstick, but I don't know.
Good: They had more time than the competition, and are an enormous company, yet managed to still ship a half-baked product with major bugs like random slowdowns promised to be fixed in a future update.
HP has never been fast. Just integrating the Palm product into their corporate structure probably took most of that time. But that's still their bad.
Cheap: Worst of all, they have decided to price the TouchPad as a premium tablet, about the same as the iPad2, or Samsung Galaxy Tab. They couldn't stand taking a few video-game-console-style quarters of losses to build market share for their nascent ecosystem?
I think this is the most dangerous, but perhaps not as much as it seems. It's a gamble that controverts the classic 'buy the market' tactic. They are betting that even with a higher price point they can get sufficient market share to meet their objectives and maintain long term growth and success. HP has the resources to keep it going for long enough to develop a stable niche (a longer, slower way of buying share), and with a higher price point they can both play the 'quality' card and have more profit margin to develop newer and better future products - IF they can actually sell enough of them in the long term. This goes back to their strategy of integrating WebOS apps on their very large Windows PC presence. That is reminiscent of the Apple integration strategy. I think they will make this a very business-oriented integration approach, giving the enterprise users the kind of integration to their internal operations applications as the iPad has to the consumer. It may work, but it may not. Again, HP can afford to take the long slow road, they would have a ready and very stable corporate market (in the process beating up on RIM), and it may work. It would certainly work better than trying to fight it out in the commodity Android space, where price will be so important.
That is an interesting and valid point. The classic marketing lesson is that "whoever is late to the market must 'buy' market share" - the best case in point that I know of was the original handheld scientific calculator market where, oddly, HP was at one time king. HP basically owned the scientific calculator market with the HP35, 45, 55 and 65 with market share close enough to 100%. These machines used 'reverse Polish notation', which made for a very efficient stack-based parser. Texas Instruments decided they wanted this market, and for years sold their calculators for at or below cost. According to estimates back then they were losing $30 on each one, for a total of hundreds of millions of dollars. But the combination of cheaper products and 'easy to use' algebraic notation finally gave the TI calculators their advantage in the schools, leaving the HP calculators to the geeks and purists.
Let us assume that modern handheld-digital-thingy markets are not so binary in nature,and the potential feature set means that there will be niches for many similar products with different 'hooks' for different types of users. If so, then HP only has to find a significant niche where they can distinguish themselves and protect their 'turf'. As you point out, they have a powerful advantage in the Windows connection, if they can protect it and follow through with cool apps that take advantage of that to provide the kind of seamless integration that Apple is noted for.
Of course I haven't used a Mac in years, and I rarely use Windows, so none of that will matter to me - I _hope_ that they will provide a good API so folks can do the same kind of integration with Linux platforms. That would provide a small but important additional advantage. Another lesson I learned in the tech industry is that the best ideas for advancing the technology comes from the users. So supporting an API and encouraging developers to use their platform might help to consolidate their base.
Oddly enough, I'm a long term Palm developer but haven't ever built anything for the Palm.
IANA HW geek, but I learned this lesson vicariously a long time ago: "Never design to the spec." Chips (TTL in this case) vary in performance, and some of them do better than spec, others do worse. In the particular case, the TTL-based CPU had a stack that was implemented using four chips (IIRC FIFOs, but I don't recall). The timing was based on the spec. As a result, those four 'identical' chips had to be matched - if a slower one came after a faster one, the CPU would crash. The difference in timing was too small to reliably measure, so manufacturing or repairing these boards involved careful testing and trials until you got a set that worked through all the diagnostics.
Of course, that was back in the day when a CPU came on one or more large circuit boards that always carried at least a few little red wires to fix hardware bugs. Even IBM CPUs. It was always gratifying to see the IBM techs at a tradeshow madly going at their server with duck tape and chisel like the rest of us.:)
I'd say close enough for gov't work, or for my tiny little brain:) Alpha particles:
Alpha particles (named after and denoted by the first letter in the Greek alphabet, ) consist of two protons and two neutrons bound together into a particle identical to a helium nucleus,... The nomenclature is not well defined, and thus not all high-velocity helium nuclei are considered by all authors as alpha particles. As with beta and gamma rays/particles, the name used for the particle carries some mild connotations about its production process and energy, but these are not rigorously applied.
Yep, I was there (almost) - some of my first programs were written in IBM 1130 Assembler.:) The machine had 16Kx16bit core, a 1 MB single-platter disk with a one second mean access time. I managed to thrash the poor beast once by nesting too many macros. The key fact is that the control program (pretty close to what we now call a kernel) was on the outside of the disk, the macro-assembler was in the middle, and the user programs were on the inside (or vice versa - I don't recall now). With only 16K of memory, everything the machine did had to be overlaid - except for about 200 bytes or so (I don't recall the number) of code that stayed resident during a job, that basically just knew how to get the next piece off the disk. That could now be called a very primitive kernel.
I suppose this could be considered equivalent in some ways to a bootstrap loader except it continued bootstrapping the various pieces in throughout the process of running a job. Every piece of code had to be loaded over the previous piece in order to run, and each time what we would now call the machine state had to be written to disk. So for each macro call, the machine had to swap bits of kernel, assembler and user code in and out, moving from the inside, to the outside, to the middle, to the outside, to the inside, etc., rinse & repeat. With a one-second access time the 15 minute maximum run time was exceeded before the assembler even finished assembling my 10 or 15 punched cards into machine code. It was a very compact program, but I never did get to run it in its full macro-bedecked glory. I had to turn the program into 100 or so cards of non-macrofied assembler.
I also (much later) had the fun of entering entire programs into an early microcomputer by flipping front panel switches, pushing the 'step' button, flipping panel switches, etc. - make one mistake, push 'reset' and start over. Seymour Cray, when he was still at Control Data Corporation (CDC) was famous for being able to enter the entire 6000 word control program into the early CDC machines from memory using the front panel switches.
So I would say that until we started getting into time-sharing and such complexities, the idea of a kernel wasn't really relevant - there was little or nothing resident in the computer's memory. I think I could safely say that is primarily what a kernel does in a modern multitasking system - provides the environment by which tasks can move safely and efficiently through the system. And the operating system includes all those non-kernel tasks, such as accounting, access control, logging, the many utilities required to provide everything from I/O to temperature control.
In computing, the kernel is the central component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).[1] Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls.
Operating system tasks are done differently by different kernels, depending on their design and implementation. While monolithic kernels execute all the operating system code in the same address space to increase the performance of the system, microkernels run most of the operating system services in user space as servers, aiming to improve maintainability and modularity of the operating system.[2] A range of possibilities exists between these two extremes.
Whoof, we're going to get into the semantics of what an OS is here! My reference to RMS was not so much about discretion, but by his reputation for enthusiasm for discussing the topic.:)
However I will refer to this quote, from Wikipedia to justify my stance that the kernel is not the OS, but a part of the OS. I will add that I've used many operating systems over the years, and the 'OS' has always referred to the complete package - kernel, core libraries, userland applications, IO and other hardware drivers, etc.
GNU/Linux is a term promoted by the Free Software Foundation (FSF), its founder Richard Stallman, and its supporters, for operating systems that include GNU software and the Linux kernel.[1] The FSF argues for the term GNU/Linux because GNU was a longstanding project to develop a free operating system, of which they say the kernel was the last missing piece.[1]... Torvalds wrote, "Sadly, a kernel by itself gets you nowhere [...] Most of the tools used with linux are GNU software."[20] Torvalds also wrote during the 1992 Tanenbaum-Torvalds debate that, "As has been noted (not only by me), the linux kernel is a miniscule part of a complete system".[21]
... in his opinion. We don't have any way of knowing if he's right, or the board's right (they have much more focus on keeping the doors open, and if the company has investors, they probably want to see an exit strategy, like selling stock in a company that's worth something). He may be too 'pure' to run a business at this level. Most business management tends to be good at a certain size, and not so good as the company expands to the next level. The company may have simply outgrown him. I don't know if that is what is happening, but it's possible.
As I recall, the free downloaded version includes some hooks for Opera to make money from advertisers. IIRC they are discreet and don't get in the way much but I haven't used it for a while. In fact I just started it up and looked around, and can't find any advertising-type things, so it must be very discreet. If you pay for it, those advertising things disappear.
Strictly speaking, Linux is the kernel - the 'entire OS' is properly GNU/Linux. Most of the core applications and libraries are from GNU. Ask Richard Stallman, he'll provide a couple of hours of instruction this topic, I'm sure.
But in the long run, if they want to track you nomatter what, they can, and they will find you. Apocryphal story, supposed to be true but I have no confirmation. A LOOONG time ago (before ARPANET became Internet), a friend of a friend was recruited out of college by NSA (whose existence at that time was either still classified or had only recently been declassified IIRC - I don't recall, but it was about that time). So he went to this interview in a building with no name on it. His escort came to get him from reception, and clamped a handcuff on his wrist - the other was on the escort. He was told that if he got more than a few feet from the escort, he might be shot. To exemplify that fact, there were armed guards in front of many doors.
My friend-of-friend was totally spooked, and the interview did not go well from his POV. So when he left, instead of flying back to New York, on the spur of the moment, he hopped a different flight to visit his girlfriend in Chicago. The next morning, there was a knock on his girlfriend's door. At the door was an NSA rep, saying "We would like to offer you a position." Astonished, my friend-of-friend asked him how he found him. The rep replied, "Don't be silly, this is the NSA!"
And that was back when finding you was relatively hard, compared to now.
To get right down to it, the real purpose of all benchmarks is to provide grist for geeks to argue about which toy is better at doing X. So, the more benchmarks the better, ideally each measuring not-quite-the-same-thing and not-quite-the-same-way. That way, everybody can have a favorite, and everyone can win!:)
It was at least 20 years ago that researchers had systems that could track flies around a room and zap them out of the air (without hurting anything else). Sorry, don't recall where I learned that - it was a long time ago.
Indeed. The Navy does not like the logistical hassles involved in delivering munitions to the ships in the middle of a war. It makes everything more expensive. FEL and rail guns can use the excess power, and suddenly the only things that need to be delivered to the ship are food and operational supplies - no more bullets, missiles, torpedoes(maybe), etc. Suddenly a task force has a much longer time on the battle line without needing resupply.
The barrel has a lifetime of one shot _now_. That is expected to change, in contrast to the target lifespan.:)
I was just thinking - what if the surface of the barrel was actually a liquid of sorts? Obviously there are issues with keeping it in place for any shot that isn't dead level, but there might be a way - like using a thixotropic material that is viscous until moved (like mayonnaise). Then it could be reformed quickly, or new material might just flow down from a series of spray nozzles. Like that stuff with the iron particles in it, that can be held in place magnetically (which raises other issues, but it's just a hypothetical example).
Slashdot Mirror
I've seen you before. You are basically stuck in a box. (the box of your preconceptions and way of thinking) That box is pretty closely related to the 'union thug' box, not to put too fine a point on it. That box pretty well destroyed Detroit over a period of 40 years. That box will prevent you from ever succeeding beyond a low level, unless you change jobs, get an MBA and go to work for the next group of Wall Street sociopaths (no, not all WS folks are sociopaths, but they're always out there - a separate topic).
When you take a job, you are providing a service in return for pay. This is a standard bargain, just like when you get a haircut. The barber offers a service, and you pay the barber. If the barber gives you an attitude, or doesn't do a good enough job, you will go somewhere else next time. If he/she does a real crap job or pisses you off enough, you won't pay him. But if he does a very good job, has a good attitude and goes above the standard, you might tip him extra.
Similarly, if you do a bit above the standard, look for how to make the company succeed, at most (not all) companies you are likely to be noticed, and sooner or later are more likely to be promoted, given a raise, or in bad times, less likely to be laid off. Sure, some companies don't follow that model - but even then, if you have done the right thing, at least _some_ of the folks in almost any company will be available to give you a good reference when you go somewhere else. So it's just good marketing unless you're a scam artist.
I used to work in the oil exploration business. There are about 30,000 oilfield engineers in the world. It's essentially a small town. If a field engineer made a mistake, that was usually not fatal. But if an engineer screwed somebody over, or failed to carry through on a promise, everybody in the business knew about it soon enough. If that happened enough times, that engineer would eventually be unable to get a job anywhere in the business - or would end up working from some scab outfit working with old crap equipment and cutting corners wherever they could.
Just so you know, the above is not a fantasy. It's exactly how things have worked for me, most places, most times, through a 40 year career. Because I always tried to do the best for the company, even when things didn't work out, I could honestly tell potential employers what I did do, what didn't work out, and why. And I never got negative feedback as a result. Potential employers can smell a rat, and unless they are rats as well, prefer not to hire them.
Me too. I've fired, and seen fired, people who were too 'effective' at making themselves the single point of failure. Usually they were also irritating, whiny SOBs who had a talent for sabotaging others' work.
Conversely, while I'm naturally an introvert and work best on my own, in my present job I've been very successful at using my own efforts to include others in my projects. It's improved my work, it's improved the stability of part of the IT universe that I'm involved in (many people know at least something about my work), it's improved my position in the company. I'm almost certainly considered more 'necessary' as a result. I suppose this could be considered 'dynamic necessity' as opposed to 'static necessity' where 'static necessity' means, more-or-less, "he's the only one who knows how that POS program works."
By putting my own work into a Mercurial repository, using dotProject and Trac to manage my own one-man projects and encouraging code reviews and release management of my projects into production IT, the others in this small company were gradually introduced to more-or-less modern project practices, and essentially had to get used to using these tools in order to integrate my work into the production environment. At first only a fraction of that group were interested, but now this has succeeded to the extent that the entire IT staff is now adopting essentially the system that I and the others in my group have been using. In the process, several other people have at least reading knowledge of how my code works, and how it fits into the bigger systems. And that integration process is now documented reasonably well so others can figure it out later.
(One clue - the Trac wiki makes a natural place to make notes while one is figuring out how to build a system, and in the process. Those notes are easy to convert into formal docs later. So those weird little facts and real-world idiosyncracies that affect how the code works are documented both in the code, and in the wiki.)
I like it!
Hmm. Fortunately most of us boomers were too stupid to save any money, so they can't afford to retire for another 10 or 20 years. That should actually help out SS.
A majority of sites that I go to (especially news sites) do not work correctly unless both cookies and javascript (at least _their_ javascript, plus maybe Google API, if not a bunch of third party javascript). And the pool of sources for that stuff that is required to make things work is expanding at a high rate. So one can not just block all cookies all the time. So one has to allow or disallow on a site-by-site basis. Installing the extensions (NoScript, Adblock, et al) is the easy part. After that it requires dealing with the NoScript options on almost every site. I do it, and it's helpful, but it's not trivial. A lot of sites use flash for video or slideshows or audio, that won't load unless you allow scripts at least temporarily. I'm not disagreeing, just whining. &_&
I listened to a keynote speech by a futurist at the 2001 O'Reilly Open Source Conference in Monterey California. He was talking about how existing technology would be used. Among other things, when you went to the mall face recognition systems (along with other stuff like wi-fi and bluetooth snooping) would attempt to figure out who you are. You would have HW that tries to prevent that by jamming or other means. Then as you walk down the entry hall, floating holographs would appear in front of you with sound only you can hear (sonic holography), saying "Ah, Mr. Doofus, welcome back. Two years ago you bought sneakers at Shoes-R-Us. Those are probably worn out. Shoes-R-Us is no longer here but Joe's Sneakers is offering you 20% off on all sneakers, just for you. Turn at the next corridor on the left. And that blouse your wife looked at two weeks ago at SuperMs is still available. Perhaps you'd like to get it for her birthday? SuperMs can give you 10% off just for today."
For myself, I'm gonna live in the woods, or on the ocean - far from any mall.
IOW, for GA we (our eyes) are the product, not the consumer.
I have had GA blocked in NoScript for a long time. I don't know if it has any real effect, of course. Maybe I'll check out the topic of this /. article just to see if it has any effect. I also blocked doubleclick.net permanently a long time ago after one too many pop-ups. I don't block everything either with NoScript or AdBlock, just those that are offensive, obtrusive and/or creepy. I feel that letting them show me ads is part of the bargain. But knowing the size of my underwear is not.
Boy, been there, done that, burned the t-shirt. As a VP R&D in a startup a long time ago (early 1990s) I once spent two months with my software manager doing a complete system plan for a complete rewrite, rearchitecture and platform change (including converting from several languages to C), down to the function level, with good estimates of the time it would take to do every piece of it. This was a product with several hundred thousand lines of code in FORTRAN, Pascal, Assembler of various sorts, maybe some C, and microcode for a custom image processor. It came down to six engineers and about two years. We got approval for that project plan at the board meeting.
Then one of the engineers mentioned to the head of sales that he thought we would 'have an image on the screen' (meaning we would have figured out how to write a toy/test program to paint a window) in about two months.
Within a few days, the sales guy had promised delivery of two systems in ... you guessed it ... two months, to GE. Oh, and by the way - the company didn't have the cash flow to hire more engineers, so we only had two guys available to the project. As it happened, I quit a week or so later for other reasons. According to what I was told later, by conspiring with the users at GE who agreed to receive the boxes, they managed to ship two completely non-functioning systems to GE, and spent the next two years 'fixing' it while the folks at GE got more and more pissed. I think GE finally sued them. After numerous equally dicey escapades, the company got forced into bankruptcy.
I think HP is in a different market than Apple. Apple's success is still mostly in the consumer space. HP has major market share in the corporate and business space, and is making noises about integrating WebOS on the PC with WebOS on the Touchpad and other devices. That market is less price sensitive, is two or three years behind the consumer market trends, considers performance less important than "works with SAP" - or QuickBooks, and is _very_ interested in working with a strong, big, reliable (if unsexy) company like HP.
So I think HP is going to own the corporate *pad business, but it will take three to five years.
Yes. Also, HP doesn't need consumers so much as business, where they sell most of their PCs. So I predict that there will be a lot of integration of WebOS on the PC to 'enterprise' apps like SAP, and extending that integration to the Touchpad to provide 'secure instant remote access' to the corporate data from anywhere. The larger form factor of a 'pad makes it a perfect growth path from the crackberries and things of that ilk. IMHO HP is better positioned for this market than anyone.
I don't think the 'late to market' question applies, as this market tends to lag the trendy consumer market by two or three years. So the present Touchpad can be a testbed for corporate developers to try WebOS apps out on their PCs and the Touchpad itself, and the next version makes those apps sing just in time for the volume buys. Look for SAP on the Touchpad.
Fast, good or cheap ...
Fast: They were late to market, with HP doing seemingly nothing for about a year. They're enormous, why didn't they hire more (or more likely, better) people if they couldn't iterate as fast as the competition.
I don't know the details of the innards of the platform software (scale or complexity) but the general rule is that adding more people - even 'better' ones - generally slows projects down and just burns money. It takes newbies to a platform a year or so to get to the point where they understand the architecture well enough to really do good work. It's possible that they spent the year just fixing architectural issues in the system, rather than painting lipstick, but I don't know.
Good: They had more time than the competition, and are an enormous company, yet managed to still ship a half-baked product with major bugs like random slowdowns promised to be fixed in a future update.
HP has never been fast. Just integrating the Palm product into their corporate structure probably took most of that time. But that's still their bad.
Cheap: Worst of all, they have decided to price the TouchPad as a premium tablet, about the same as the iPad2, or Samsung Galaxy Tab. They couldn't stand taking a few video-game-console-style quarters of losses to build market share for their nascent ecosystem?
I think this is the most dangerous, but perhaps not as much as it seems. It's a gamble that controverts the classic 'buy the market' tactic. They are betting that even with a higher price point they can get sufficient market share to meet their objectives and maintain long term growth and success. HP has the resources to keep it going for long enough to develop a stable niche (a longer, slower way of buying share), and with a higher price point they can both play the 'quality' card and have more profit margin to develop newer and better future products - IF they can actually sell enough of them in the long term. This goes back to their strategy of integrating WebOS apps on their very large Windows PC presence. That is reminiscent of the Apple integration strategy. I think they will make this a very business-oriented integration approach, giving the enterprise users the kind of integration to their internal operations applications as the iPad has to the consumer. It may work, but it may not. Again, HP can afford to take the long slow road, they would have a ready and very stable corporate market (in the process beating up on RIM), and it may work. It would certainly work better than trying to fight it out in the commodity Android space, where price will be so important.
That is an interesting and valid point. The classic marketing lesson is that "whoever is late to the market must 'buy' market share" - the best case in point that I know of was the original handheld scientific calculator market where, oddly, HP was at one time king. HP basically owned the scientific calculator market with the HP35, 45, 55 and 65 with market share close enough to 100%. These machines used 'reverse Polish notation', which made for a very efficient stack-based parser. Texas Instruments decided they wanted this market, and for years sold their calculators for at or below cost. According to estimates back then they were losing $30 on each one, for a total of hundreds of millions of dollars. But the combination of cheaper products and 'easy to use' algebraic notation finally gave the TI calculators their advantage in the schools, leaving the HP calculators to the geeks and purists.
Let us assume that modern handheld-digital-thingy markets are not so binary in nature,and the potential feature set means that there will be niches for many similar products with different 'hooks' for different types of users. If so, then HP only has to find a significant niche where they can distinguish themselves and protect their 'turf'. As you point out, they have a powerful advantage in the Windows connection, if they can protect it and follow through with cool apps that take advantage of that to provide the kind of seamless integration that Apple is noted for.
Of course I haven't used a Mac in years, and I rarely use Windows, so none of that will matter to me - I _hope_ that they will provide a good API so folks can do the same kind of integration with Linux platforms. That would provide a small but important additional advantage. Another lesson I learned in the tech industry is that the best ideas for advancing the technology comes from the users. So supporting an API and encouraging developers to use their platform might help to consolidate their base.
Oddly enough, I'm a long term Palm developer but haven't ever built anything for the Palm.
IANA HW geek, but I learned this lesson vicariously a long time ago: "Never design to the spec." Chips (TTL in this case) vary in performance, and some of them do better than spec, others do worse. In the particular case, the TTL-based CPU had a stack that was implemented using four chips (IIRC FIFOs, but I don't recall). The timing was based on the spec. As a result, those four 'identical' chips had to be matched - if a slower one came after a faster one, the CPU would crash. The difference in timing was too small to reliably measure, so manufacturing or repairing these boards involved careful testing and trials until you got a set that worked through all the diagnostics.
Of course, that was back in the day when a CPU came on one or more large circuit boards that always carried at least a few little red wires to fix hardware bugs. Even IBM CPUs. It was always gratifying to see the IBM techs at a tradeshow madly going at their server with duck tape and chisel like the rest of us. :)
Indeed. I don't know if it's still true, but for many years MS Windows FTP client binaries included the original BSD attribution. :)
I'd say close enough for gov't work, or for my tiny little brain :)
Alpha particles:
Alpha particles (named after and denoted by the first letter in the Greek alphabet, ) consist of two protons and two neutrons bound together into a particle identical to a helium nucleus, ...
The nomenclature is not well defined, and thus not all high-velocity helium nuclei are considered by all authors as alpha particles. As with beta and gamma rays/particles, the name used for the particle carries some mild connotations about its production process and energy, but these are not rigorously applied.
Yep, I was there (almost) - some of my first programs were written in IBM 1130 Assembler. :) The machine had 16Kx16bit core, a 1 MB single-platter disk with a one second mean access time. I managed to thrash the poor beast once by nesting too many macros. The key fact is that the control program (pretty close to what we now call a kernel) was on the outside of the disk, the macro-assembler was in the middle, and the user programs were on the inside (or vice versa - I don't recall now). With only 16K of memory, everything the machine did had to be overlaid - except for about 200 bytes or so (I don't recall the number) of code that stayed resident during a job, that basically just knew how to get the next piece off the disk. That could now be called a very primitive kernel.
I suppose this could be considered equivalent in some ways to a bootstrap loader except it continued bootstrapping the various pieces in throughout the process of running a job. Every piece of code had to be loaded over the previous piece in order to run, and each time what we would now call the machine state had to be written to disk. So for each macro call, the machine had to swap bits of kernel, assembler and user code in and out, moving from the inside, to the outside, to the middle, to the outside, to the inside, etc., rinse & repeat. With a one-second access time the 15 minute maximum run time was exceeded before the assembler even finished assembling my 10 or 15 punched cards into machine code. It was a very compact program, but I never did get to run it in its full macro-bedecked glory. I had to turn the program into 100 or so cards of non-macrofied assembler.
I also (much later) had the fun of entering entire programs into an early microcomputer by flipping front panel switches, pushing the 'step' button, flipping panel switches, etc. - make one mistake, push 'reset' and start over. Seymour Cray, when he was still at Control Data Corporation (CDC) was famous for being able to enter the entire 6000 word control program into the early CDC machines from memory using the front panel switches.
So I would say that until we started getting into time-sharing and such complexities, the idea of a kernel wasn't really relevant - there was little or nothing resident in the computer's memory. I think I could safely say that is primarily what a kernel does in a modern multitasking system - provides the environment by which tasks can move safely and efficiently through the system. And the operating system includes all those non-kernel tasks, such as accounting, access control, logging, the many utilities required to provide everything from I/O to temperature control.
Just to put a stamp on this, Wikipedia on Kernels:
In computing, the kernel is the central component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).[1] Usually as a basic component of an operating system, a kernel can provide the lowest-level abstraction layer for the resources (especially processors and I/O devices) that application software must control to perform its function. It typically makes these facilities available to application processes through inter-process communication mechanisms and system calls.
Operating system tasks are done differently by different kernels, depending on their design and implementation. While monolithic kernels execute all the operating system code in the same address space to increase the performance of the system, microkernels run most of the operating system services in user space as servers, aiming to improve maintainability and modularity of the operating system.[2] A range of possibilities exists between these two extremes.
Whoof, we're going to get into the semantics of what an OS is here! My reference to RMS was not so much about discretion, but by his reputation for enthusiasm for discussing the topic. :)
However I will refer to this quote, from Wikipedia to justify my stance that the kernel is not the OS, but a part of the OS. I will add that I've used many operating systems over the years, and the 'OS' has always referred to the complete package - kernel, core libraries, userland applications, IO and other hardware drivers, etc.
GNU/Linux is a term promoted by the Free Software Foundation (FSF), its founder Richard Stallman, and its supporters, for operating systems that include GNU software and the Linux kernel.[1] The FSF argues for the term GNU/Linux because GNU was a longstanding project to develop a free operating system, of which they say the kernel was the last missing piece.[1] ...
Torvalds wrote, "Sadly, a kernel by itself gets you nowhere [...] Most of the tools used with linux are GNU software."[20] Torvalds also wrote during the 1992 Tanenbaum-Torvalds debate that, "As has been noted (not only by me), the linux kernel is a miniscule part of a complete system".[21]
... in his opinion. We don't have any way of knowing if he's right, or the board's right (they have much more focus on keeping the doors open, and if the company has investors, they probably want to see an exit strategy, like selling stock in a company that's worth something). He may be too 'pure' to run a business at this level. Most business management tends to be good at a certain size, and not so good as the company expands to the next level. The company may have simply outgrown him. I don't know if that is what is happening, but it's possible.
As I recall, the free downloaded version includes some hooks for Opera to make money from advertisers. IIRC they are discreet and don't get in the way much but I haven't used it for a while. In fact I just started it up and looked around, and can't find any advertising-type things, so it must be very discreet. If you pay for it, those advertising things disappear.
Strictly speaking, Linux is the kernel - the 'entire OS' is properly GNU/Linux. Most of the core applications and libraries are from GNU. Ask Richard Stallman, he'll provide a couple of hours of instruction this topic, I'm sure.
But in the long run, if they want to track you nomatter what, they can, and they will find you.
Apocryphal story, supposed to be true but I have no confirmation. A LOOONG time ago (before ARPANET became Internet), a friend of a friend was recruited out of college by NSA (whose existence at that time was either still classified or had only recently been declassified IIRC - I don't recall, but it was about that time). So he went to this interview in a building with no name on it. His escort came to get him from reception, and clamped a handcuff on his wrist - the other was on the escort. He was told that if he got more than a few feet from the escort, he might be shot. To exemplify that fact, there were armed guards in front of many doors.
My friend-of-friend was totally spooked, and the interview did not go well from his POV. So when he left, instead of flying back to New York, on the spur of the moment, he hopped a different flight to visit his girlfriend in Chicago. The next morning, there was a knock on his girlfriend's door. At the door was an NSA rep, saying "We would like to offer you a position." Astonished, my friend-of-friend asked him how he found him. The rep replied, "Don't be silly, this is the NSA!"
And that was back when finding you was relatively hard, compared to now.
To get right down to it, the real purpose of all benchmarks is to provide grist for geeks to argue about which toy is better at doing X. So, the more benchmarks the better, ideally each measuring not-quite-the-same-thing and not-quite-the-same-way. That way, everybody can have a favorite, and everyone can win! :)
It was at least 20 years ago that researchers had systems that could track flies around a room and zap them out of the air (without hurting anything else). Sorry, don't recall where I learned that - it was a long time ago.
Indeed. The Navy does not like the logistical hassles involved in delivering munitions to the ships in the middle of a war. It makes everything more expensive. FEL and rail guns can use the excess power, and suddenly the only things that need to be delivered to the ship are food and operational supplies - no more bullets, missiles, torpedoes(maybe), etc. Suddenly a task force has a much longer time on the battle line without needing resupply.
The barrel has a lifetime of one shot _now_. That is expected to change, in contrast to the target lifespan. :)
I was just thinking - what if the surface of the barrel was actually a liquid of sorts? Obviously there are issues with keeping it in place for any shot that isn't dead level, but there might be a way - like using a thixotropic material that is viscous until moved (like mayonnaise). Then it could be reformed quickly, or new material might just flow down from a series of spray nozzles. Like that stuff with the iron particles in it, that can be held in place magnetically (which raises other issues, but it's just a hypothetical example).