requires a good mechanical connection before attempting to solder. The general rule is that it should work without the solder. Of course this isn't always practical, in fact surface mount is just held on by the solder. Rules are made to be broken! lol
Re enable the runas service (it's on by default). Now try right clicking an exe with the shift button held down. See that "Run As..." menu item? Click it, now the program will run with alternate use privledge. Welcome to NT... What I want to know is why 99% of the fscking setup programs need to run as admin to install simple little applets into my user context..
...by now, it's a straightforward proposition to manufacture cores at low cost. Device makers are still trying to figure out how to put together ARM devices that land in impulse-buy territory
I don't think it has anything to do with the cost of the ARM. There are numerious manufactures (Atmel, cirrus, etc) that are selling ARM microcontrollers for just a couple of $. Its more a problem of thinking up cool things to do with a CPU, that doesn't have a lot of RAM, (for mp3's etc) or a display attached that cannot be done with a little 15 cent PIC, or a 50 cent 8051.
Accually, in a lot of cases all M$ needs to do is flip a bunch of the defaults to the more secure setting and a whole bunch of applications won't install or run properly. I run as a non administrative user in 2000, and I'm always hitting applications that want to modify a HKEY_LOCAL_MACHINE registry entry or some system specific file. Its completly uncalled for 99% of the time. Why does a cheezy 3rd party email client need to change the global settings, instead of my local user prefrences. Its like web pages, change your security settings to a little more restrictive and suddenly some cheezy web page refuses to work instead of running in a degraded mode.
I am a driver developer: A year or so ago a company I worked for was looking to release a linux driver. The same questions were going around and around. Some other things to think about.
There are lots of diffrent versions of Linux. This isn't windows where you have to make a release for one or two versions of the same operating system. This will cost money in terms of support and testing. Every driver release will have to be testing with the kernel version shipped with the last couple release of Red Hat, Mandrake, Suse, and Turbolinux at a bare minimum.
Getting a driver to work across multiple major linux verions (2.2->2.4->2.6) isn't usually a small task if your driver does more than export a basic character device. In some cases it is as easy to port to AIX and Solaris than keep up with how fast people are changing the Kernel API's. There has been talk of changing this on LKML.
You have to have a solution to deal with people who are installing kernel patches which break API's you depend on. In our case the driver was carefully written to have an opensource component and a closed source component. The user could download and compile the opensource part which would provide a stable API for the closed source part.
You also have to question your basic model. Is your company selling hardware, software, support or a combination? If your not selling software then why are you concerned about the driver? Simply opensource it. That way you will get free development. The bottom line may be a better if you hire 1 developer to write and release a opensource driver which gets partially maintained by the community vs two or three developers to write, maintain and test it.
If your releasing a new piece of hardware that doesn't have market acceptance yet and isn't just another cheaper/faster soundcard/nic/etc then you probably want to encourage use of your product. Opensource drivers help to document and provide examples of how to use the hardware. I have been involved in a situation recently where a company has been trying to sell a product for two or three years into a particular market. We are selling product into a diffrent market. After trying to buy a development kit and aquire documentation we went with another solution that has very open documentation (including some opensource driver source to look at).
There isn't anything particulary special about 99% (statistic pulled from ass) of the drivers out there. They are simply software intefaces between the OS API's and a particular piece of hardware. Just because it cost a lot money to make the driver doesn't mean it should cost a lot. Drivers by definition are pieces of code writtent to SUPPORT the hardware. Not the other way around. Viewing the driver as the cost of selling the HW (just like the marketing costs of selling it) is much more appropiate. Will you try to have a license key for the driver or will the HW be the license key? Most companies give the latest version of the driver away on their web site, why not provide the source anyway. Any patents in the source are still valid, and it discourages people from reverse engineering your driver and writing a clean room version you don't control.
I firmly believe that if this starts to become prevalent a return to the 'BBS' days will result. Only this time instead of fidonet running over 9600bps modems. It will be apartment complexes/neighborhoods etc tied to each other over dark fiber links served to their users with high speed short distance wireless. Already where I live there are numerous apartment complexes that provide 'free internet' as part of the rent. Companies like Cogent will be more than happy to provide high bandwidth backbones between major cities.
Well, I just purchased my second palm device this weekend. I would have stuck with the old one had it not commited suicide from the top of my gym locker. I'm not a particularly large palm fan. After all for the most part the problem with palm is that you can buy a device from 1997 today for exactly the same price. Ok, the processors are slightly faster and the new devices have more RAM (unless your talking about the zire). Other than that they are pretty much the same.
On the other hand I stuck with palm because its a useful device. I have a good graphing calculator for it, and I use it like a standard day planner with a book/news reader. My old palm IIIxe was great on batteries. They only required changing once ever few months. Combine that with the fact that the battery monitor accually seemed somewhat accurate meant that I had plenty of warning to change them. I don't want to have to carry a charging station for a week long trip. So, when I went looking for a new one I had a few things I wanted. Higher res, color screen, mp3 player, smaller, faster, more ram.
Well it turned out I bought a m500 not something with a higher res screen, color, mp3 player, or a device with more ram. I purchased it simply because it was the smallest palm I could find. My second choice was one of the little cli devices because of the higer res screen. The only problem is that for most applications the high res screen seems to be run in low res, the color isn't particularly useful, its nice to have... and its probably about 50% thicker than the m500. The m515 might have been a good choice if it had been the same size as the m500 (its about 30% thicker).
So in the end the deciding factor was size, my importance factors went something like. Size most important, Useful battery life, high res display, ram, color, mp3 playback. In the end I came away from the whole market pretty discusted. The m500 isn't as small as I want (pcmcia card size), it has the same amount of ram(8 megs worked on the old device should contine to work) and the display is the same crappy low res greyscale.
Lots of software is the equivilant of those pictures. The only problem is that you can't see that from the pretty pictures on the box cover. Instead you see it in crashes and strange behavior. Two things cause it, first unskilled careless workers, second stressed workers in unrealistic situations. The second seems to be more previlant. They guy who wired that first mess probably knew that its better to label everything and run it down the side of the rack to the gutter in the floor (notice the one rack is accually nicely wired under the mess on top). Instead you have the manager who gives you 1 day to wire up 100 computers, or 1 week to add some big feature to the code base. The result is scrambling like mad and a "just plug it in and make it work don't make it pretty" attitude.
Even out west (others comments ignored) this is true. To a lesser extent yes, but all that desert is often fenced off and grazed. Just because you don't see the herd from the road doesn't mean they aren't there. From the air its a lot more obvious. Little squares bounded by roads, mountains etc, with a house and a group of cattle in one corner or the other.
I read a statistic a few years ago in a outdoors magazine which said that there isn't anywhere in the continental US if you pick the correct direction and walk, you won't hit some form of human civilization (road, house etc) within a day. It also said that there are only a few places in the US that if you randomly pick a direction and walk that its actually possible to take more than a day to reach civilization. Ever since reading that I am depressed when I look at the road atlas and am unable to find big blocks of land without any roads.
How about I present you will the other side of your unlikely situation.
If an angry mob (with or without guns take your pick, although I should point out most angry mobs in the US in the last few years were partially armed) were to attack your neighborhood. Would you want to have a gun to defend your home, wife and children? On the other hand you can call the police, and hope they can get though in time, or you can hope that you can escape from your house trailing your wife and children and hope that no one catches you, or your loved ones. Again, if you decide to run would you like to have a gun with you?
Ah yes, and of course the police do nothing that giving everyone a gun wouldn't. It's like I've always said: you can't beat a heavily-armed lynch mob for a meticulous and professional criminal investigation leading to a fair and open trial.
Actually, the police do little to stop real crime (i'm not talking speeding tickets here i'm talking robberies, assault, murder, etc.). They are little more than glorified paper pushers labeled as a deterrent. Basically you have to commit murder before any investigative part of the police force is brought in. The local police where I live, always give the lame excuse that they are undermanned (even though there is like 1 cop per 100 people in the city). Its more like they are to busy enforcing traffic violations and petty civil issues (loud music, arresting people who haven't paid their late tickets etc.) to do anything except show up and write an incident report when a real crime occurs.
I am apparently one of the few people who doesn't take the "we need more police" line seriously. More police != lower crime rate. Even though that is usually the reason given to hire more. Instead I see 50 cops standing on street corners "showing presence" in groups of three or so on a friday night when I go downtown to drink. Since, the town I live in is pretty laid back its rare to actually see them doing anything. Most of the 'disturbances' probably occur in the bars which already have hired security there to check id's and deal with such problems.
Basically what i'm getting at, is you probably have a better chance of stopping crime if nearly everyone carried a gun. Effectively, you have a 99% of the population as a police force. Instead of the first instinct being "call the police!" the first instinct should be "lets go stop that!" Five to ten minutes later when the police show up there is a good chance that the burglar has run off with a few valuable things, the rapist has finished up and ran away, or the murderer is half way across town.
Acually, it looks like it might be getting some lift from the body (ie lifting body). It could also apply to the big engine, small plane theory. Which says given enough thrust anything will fly. For example, the shuttle. I seriously doubt the second given its speed but I don't know what its operating limits are. It might require 275 knots to take off and have a max speed of 300..
You can get a cheap one for the price of a medium cost big screen TV. I can tell you a 10' wide screen (or whatever the wall size i'm using right now is) at 10 feet away is just as impressive as sitting in a theater. I have the additional advantage of lying down while watching movies and drinking beer.
I was reading their page and had this thought exactly.
The Large RealLike is based on the 'average' male penis. With our data we have gathered from Venus 2000 users we know what 'average' really is! It even has all the bumps and ridges of the real thing.
I bet they have a larger more accuate sample size than most 'science' projects... Only problem is that they don't have the dimensions on the web page. LOL
That is pretty funny. It gives me a lot of confidence about the OS/software! Think about how many bugs you can't see if there is a glaring one on the example screen shot!
You are correct, I was going to point this out myself. Every 'RISC' arch I've used (even the ARM) has some save a group of registers instruction. But...!!!! There is a cost. Most of these instructions take many cycles to execute, so they just as well could be 10+ instructions. Latency is latency. The real savings is in code density. The real cost is in processor complexity. Besides the fact that this instruction and a couple others usually add an extra decode stage which breaks the 'Complex' instruction into more fundamental simple instructions. There is an exception handling issue. What happens if the instruction causes an exception (page fault,or an interrupt fires) half way through execution of the instruction? In particuar for load multiple when the instruction overwrites the register which contains the source address (diffrent PPC/POWER's handle this diffrently)? Ach ich,ugly problem, all to save a few instructions back when memory was expensive.
Oh, someone forgot to tell you that cache size is only 1/2 of the equation. The other is cache latency. A basic equation from comp-arch is that the sum of each cache/memory level's latency*hitrate gives the effective latency of the memory system.
This is great, and a first order analysis concludes that you want a really big, really fast cache. The only problem is that the bigger the cache the longer (in real time) it takes to fetch a row of data. The second part of the problem is that the processor has a fixed number of cycles (directly computable from the fetch->execute stage count) of latency it can tolerate. As the cycle times of the processor get faster (higher GHz) the amount of real time tolerances gets smaller. This means that if your processor can only tolerate a 2 cycle load to use time, then you should try really hard to get a L1 that can satisfy this. So, in this example 2 times the cycle time is the max time that the cache should have as a fetch time. Then its easy, you build the bigest cache that you can affort which can also satisfy this time requirement. Then because the L1 probably doesn't have a particularly good hitrate you repeate the process for a L2 with a slightly higher hitrate and a slightly slower latency. Contine adding cache layers until you either run out of money or you get an acceptable memory latency.
A second order analysis also includes looking at real life application hit rates and patterns. Then taking that data and using it to help make your decisions about cache size and latency. The intel engineers arn't idiots (nor are the ones at AMD, IBM etc) there is a real reason the cache is the size it is. If it didn't cost anything to double the L1 in either performace or money then you can be sure that any given processor would have 2x as much L1. Simple 0 order analysis (my cache/clockrate/dick is bigger) rarely tells even 10% of the story.
Extend it further out. There's something called "Conditional Instructions". Properly utilized, these make for an ultra efficient code cache. The processer is able to dump the code cache instructions ahead of time. Which also means, not as much unecessary "pipeline preparation" to perform an instruction.
The ARM is a cute little arch, the only problem is that EVERY instruction is conditional. At first this seems like it might make for some really nice optimizations. But its a lot harder than you think (the instruction cache cannot just dump instructions, because it has to know what the current state of the processor is, this means that all instructions which affect the condition codes have to retire before decisions about which instructions can be executed are made). When I started thinking about how I would design an OO superscalar version it started to give me a real headache. Eventually I realized about the only way (I could think of, maybe there is a better way) would be to have some kind of in order conditional retire stage near the end of the pipeline. This would allow the processor to run at decent speeds as long as the code was very careful to rarely use the conditional execution, since it would effectivly serialize the instruction stream. The 'Always' execute instructions could retire out of order as long as there was enough distance between them and the condition changing/condition dependent instructions.
All this is to say, the ARM is a nice arch for low speed, low power devices. Really high speed versions might be pretty hard to get right. Intel's Xscale is like this, everything considered, it's IPC is pretty bad.
Check out this article and the link it has to DDJ about the reason why people use VB even though its really ugly. Hint it has to do with how productive the _TOOL_ is not the language or its libraries.
Accually, you desperatly need to take a look at Kylix/Delphi/BCB from borland. Delphi is basically a cleaner VB. Right now there is a Linux port called Kylix which pretty much allows cross platform gui development. Of course it only runs on Linux/Windows, on the other hand I guarantee you will like it more than the assortment of other cross platform GUI toolkits like wxWindows & QT. Part of the VB advantage is the integrated enviroment with the way you just drop components, changes a couple properties, click on their events a write a couple lines of code and call the application complete. QT's designer is getting this way, but right now It doesn't have the component support the professional version of Delphi/BCB/Kylix have or the simple COM/ActiveX/etc target and use abilities that VB & Delphi have. I've got a small collection of 'demos' I show people from memory who have never seen what an eviroment like VB/Delphi can do. You know the kind, drop the database table component on a form, create a table with a key and a text field, tie the text field to a browser, add a couple lines a HTML into a few fields and demonstrate a couple cute tricks, or drop a scanner ActiveX (one of my development machines has a scanner) component on a form, tie it to a graphics box, write a couple lines of code tied to a button to run a RGB channel inversion filter or something simple like that.. It seems to amaze my C friends. Especially when I have one of those smooth days and do it all in under a minuite.
Ah, yes, I remember my forth work. Don't knock it, just because you don't understand it. It is a strange language. On the other hand it teaches some useful concepts, sort of like using an old reverse polish HP calculator for a year. In Forth in order to get anything reasonable done you have to break your problem up into little tiny self contained pieces. I think the resultant mindset coupled with modern component OO development helps to generate more maintainable code. People stop writing these huge do everything classes in C++/Java/etc. Instead you get these small well defined mini components.
Also consider that at some point soon, a lot of people are going to have to port their projects to take advantage of the new 64 bit processors and for the Itanium. To you it may be as simple as "a simple recompile" but we both know it's not that easy when you are using third party libraries and components. Half the world can be brought to a halt because one component vendor isn't on the ball in the Delphi/C world.
As many other people have pointed out only a very narrow subset of applications will accually see a benifit from moving to 64-bit. Database are one of them, but we arn't talking about databases we are talking about the backend logic driving them. I suspect that there arn't many systems running today that will see a huge benifit from moving to 64-bit that arn't already running on a Sun/AIX/HPUX/etc box.
Secondly, I don't see how Java solves the problem of 3rd party vendors not being on the ball. If your database vendor thinks that the 'C' libraries are more important than the java drivers it makes the problem even worse. It seems the PHB factor is what drives this.
C# doesn't support clustering, distributed transactions, nor the object persistence that J2EE supports. Do you fully understand how much effort it would take for you to write a security system and distributed transactions for your entire enterprise? How about optimization of this system?
Correct C# (c/C++/most other languages) doesn't support these features. Its supported by the enviroment, in the case of C# by.NET. Personally I find old M$ technologies like DCOM/COM+/MS Transact to be more advanced than the J2EE support. Most of this stuff has been around forever (ever use an AS400?), in many cases its easier to use than the Java version. In others its a pain in the rear. Which is sort of my original point, that Java doesn't appear to be the best framework when compared with assorted other techologies. When compared to straight C it will win, this is primarly a function of the C minset forcing everything to be explicit. Besides a lot of this isn't a particularly big deal because the database backend will guarantee a certain level of tranactional consistancy. Ebay isn't as tight as you think either, this is a function of the fact that in the end all that matters is who is the highest bidder or in the event of a tie who placed the bid first. Just as long as consitancy is maintained all kinds of 'bad' things can happen. I've accually seen "you have won this item" screens from ebay on things I placed a bid on seconds before it closed, only to have it not be true because some other sniper managed to get a bid in after mine but before the auction closed.
Ease-of-management also comes into it. Migrating servers is a lot easier when you don't have to worry about recompilation; just copy over some.class files. That's the advantage of the virtual machine: no worries about weird big-endian/little-endian bugs, 32 bit vs. 64 bit, etc
This sounds nice but, does it really work that way? How often will a large company migrate their servers running a custom application from one platform to another without bringing in someone to test and verify the system? Is the savings every few years worth the extra development cost? In the past, by the time the system needed 'migration' rather than upgrading, it was time for a completely new application. Companies migrated from the mainframes and minicomputers of the early 80's not because the couldn't handle the business anymore, but because it cost to much to maintain the old hardware or the old business paradigm the software was written for was outdated. In some cases they updated because it was cheaper to train someone to use a GUI application than the old TTY one. In 10 years will it really matter if you can migrate your business backend? Will you want to?
Finally, Java runs well on *nix, and *nix is THE choice for big, serious sites. Sun makes Solaris, and Sun makes Java; that's all that needs to be said about that.
This sounds like my last statment, the real reason for using J2EE is to avoid M$. The middle tiers apparently arn't particulary performace intensive. Combined with the fact that companies like IBM make enterprise level PC servers means there really isn't a hardware reason. (There are dozens of companies making hot swap/failover M$ solutions too.) After the sun fiasco with the processor cache bugs causing random data corruption, and the coverup, I lost all my trust in them. To a certain extent the other Unix vendors as well. For all the talk about how closed the PC is, it seems far more open than the Unix vendors. Christ, I can't even access the HP user to user support boards without proving I have a machine under warantee or a support contract. I am now applying a basdardized Open Source theorem to my hardware. 'Millions of users make the bugs shallow and hard to cover up.'
Ok, something i've never quite understood. What is the benefit of Java on the server? It sort of made sense on the client even though most companies have standard client configurations. I fail to see any advantage on the server. It seems to me that when installing / designing a back end to a n-tier system the ability to be cross platform doesn't buy you much. The servers are specified to match the application. Java's 'standard' API's for database manipulation seem to come at the cost of performance. Yes, i've heard all the arguments about java performance, but lets face it highly performance critical systems simply cannot be tuned as easily when you have a JVM between you and the hardware and a set of generic libraries between you and the database, communications etc interface. So, lets assume that the applications don't really need the performance. It then comes down to the question of whether or not Java and friends provide sufficiently high level abstractions to ease development costs. Again, I simply don't find the java tool kits sufficiently better than assorted 3rd party system, even ones not designed for building middle tier systems. Take Delphi for instance, the built in database manipulation components and its ability to handle distributed systems, aren't really its strong point (building front ends) but its secondary support in the enterprise versions seems better than J2EE. Then there are M$ offerings like C#.net. Admittedly a dirty word on/., and ignoring the M$ hype about how much faster it is, it does a damn good job at enterprise backends.
In the end it seems to me that (especially here on/.) J2EE's strongest benefit is that you can build a system without involving M$. The negative is that it seems to cost more, particularly for development.
Slashdot Mirror
requires a good mechanical connection before attempting to solder. The general rule is that it should work without the solder. Of course this isn't always practical, in fact surface mount is just held on by the solder. Rules are made to be broken! lol
Re enable the runas service (it's on by default). Now try right clicking an exe with the shift button held down. See that "Run As..." menu item? Click it, now the program will run with alternate use privledge. Welcome to NT... What I want to know is why 99% of the fscking setup programs need to run as admin to install simple little applets into my user context..
I don't think it has anything to do with the cost of the ARM. There are numerious manufactures (Atmel, cirrus, etc) that are selling ARM microcontrollers for just a couple of $. Its more a problem of thinking up cool things to do with a CPU, that doesn't have a lot of RAM, (for mp3's etc) or a display attached that cannot be done with a little 15 cent PIC, or a 50 cent 8051.
Accually, in a lot of cases all M$ needs to do is flip a bunch of the defaults to the more secure setting and a whole bunch of applications won't install or run properly. I run as a non administrative user in 2000, and I'm always hitting applications that want to modify a HKEY_LOCAL_MACHINE registry entry or some system specific file. Its completly uncalled for 99% of the time. Why does a cheezy 3rd party email client need to change the global settings, instead of my local user prefrences. Its like web pages, change your security settings to a little more restrictive and suddenly some cheezy web page refuses to work instead of running in a degraded mode.
I am a driver developer: A year or so ago a company I worked for was looking to release a linux driver. The same questions were going around and around. Some other things to think about.
There are lots of diffrent versions of Linux. This isn't windows where you have to make a release for one or two versions of the same operating system. This will cost money in terms of support and testing. Every driver release will have to be testing with the kernel version shipped with the last couple release of Red Hat, Mandrake, Suse, and Turbolinux at a bare minimum.
Getting a driver to work across multiple major linux verions (2.2->2.4->2.6) isn't usually a small task if your driver does more than export a basic character device. In some cases it is as easy to port to AIX and Solaris than keep up with how fast people are changing the Kernel API's. There has been talk of changing this on LKML.
You have to have a solution to deal with people who are installing kernel patches which break API's you depend on. In our case the driver was carefully written to have an opensource component and a closed source component. The user could download and compile the opensource part which would provide a stable API for the closed source part.
You also have to question your basic model. Is your company selling hardware, software, support or a combination? If your not selling software then why are you concerned about the driver? Simply opensource it. That way you will get free development. The bottom line may be a better if you hire 1 developer to write and release a opensource driver which gets partially maintained by the community vs two or three developers to write, maintain and test it.
If your releasing a new piece of hardware that doesn't have market acceptance yet and isn't just another cheaper/faster soundcard/nic/etc then you probably want to encourage use of your product. Opensource drivers help to document and provide examples of how to use the hardware. I have been involved in a situation recently where a company has been trying to sell a product for two or three years into a particular market. We are selling product into a diffrent market. After trying to buy a development kit and aquire documentation we went with another solution that has very open documentation (including some opensource driver source to look at).
There isn't anything particulary special about 99% (statistic pulled from ass) of the drivers out there. They are simply software intefaces between the OS API's and a particular piece of hardware. Just because it cost a lot money to make the driver doesn't mean it should cost a lot. Drivers by definition are pieces of code writtent to SUPPORT the hardware. Not the other way around. Viewing the driver as the cost of selling the HW (just like the marketing costs of selling it) is much more appropiate. Will you try to have a license key for the driver or will the HW be the license key? Most companies give the latest version of the driver away on their web site, why not provide the source anyway. Any patents in the source are still valid, and it discourages people from reverse engineering your driver and writing a clean room version you don't control.
I firmly believe that if this starts to become prevalent a return to the 'BBS' days will result. Only this time instead of fidonet running over 9600bps modems. It will be apartment complexes/neighborhoods etc tied to each other over dark fiber links served to their users with high speed short distance wireless. Already where I live there are numerous apartment complexes that provide 'free internet' as part of the rent. Companies like Cogent will be more than happy to provide high bandwidth backbones between major cities.
Well, I just purchased my second palm device this weekend. I would have stuck with the old one had it not commited suicide from the top of my gym locker. I'm not a particularly large palm fan. After all for the most part the problem with palm is that you can buy a device from 1997 today for exactly the same price. Ok, the processors are slightly faster and the new devices have more RAM (unless your talking about the zire). Other than that they are pretty much the same.
On the other hand I stuck with palm because its a useful device. I have a good graphing calculator for it, and I use it like a standard day planner with a book/news reader. My old palm IIIxe was great on batteries. They only required changing once ever few months. Combine that with the fact that the battery monitor accually seemed somewhat accurate meant that I had plenty of warning to change them. I don't want to have to carry a charging station for a week long trip. So, when I went looking for a new one I had a few things I wanted. Higher res, color screen, mp3 player, smaller, faster, more ram.
Well it turned out I bought a m500 not something with a higher res screen, color, mp3 player, or a device with more ram. I purchased it simply because it was the smallest palm I could find. My second choice was one of the little cli devices because of the higer res screen. The only problem is that for most applications the high res screen seems to be run in low res, the color isn't particularly useful, its nice to have... and its probably about 50% thicker than the m500. The m515 might have been a good choice if it had been the same size as the m500 (its about 30% thicker).
So in the end the deciding factor was size, my importance factors went something like.
Size most important, Useful battery life, high res display, ram, color, mp3 playback. In the end I came away from the whole market pretty discusted. The m500 isn't as small as I want (pcmcia card size), it has the same amount of ram(8 megs worked on the old device should contine to work) and the display is the same crappy low res greyscale.
Lots of software is the equivilant of those pictures. The only problem is that you can't see that from the pretty pictures on the box cover. Instead you see it in crashes and strange behavior. Two things cause it, first unskilled careless workers, second stressed workers in unrealistic situations. The second seems to be more previlant. They guy who wired that first mess probably knew that its better to label everything and run it down the side of the rack to the gutter in the floor (notice the one rack is accually nicely wired under the mess on top). Instead you have the manager who gives you 1 day to wire up 100 computers, or 1 week to add some big feature to the code base. The result is scrambling like mad and a "just plug it in and make it work don't make it pretty" attitude.
Besides the fact that most FC drives are FC-SCSI hu? lol.. :>
Even out west (others comments ignored) this is true. To a lesser extent yes, but all that desert is often fenced off and grazed. Just because you
don't see the herd from the road doesn't mean they aren't there. From the air its a lot more obvious. Little squares bounded by roads,
mountains etc, with a house and a group of cattle in one corner or the other.
I read a statistic a few years ago in a outdoors magazine which said that there isn't anywhere in the continental US if you pick the correct
direction and walk, you won't hit some form of human civilization (road, house etc) within a day. It also said that there are only a few places in
the US that if you randomly pick a direction and walk that its actually possible to take more than a day to reach civilization. Ever since reading
that I am depressed when I look at the road atlas and am unable to find big blocks of land without any roads.
How about I present you will the other side of your unlikely situation.
If an angry mob (with or without guns take your pick, although I should point out most angry mobs in the US in the last few years were partially armed) were to attack your neighborhood. Would you want to have a gun to defend your home, wife and children? On the other hand you can call the police, and hope they can get though in time, or you can hope that you can escape from your house trailing your wife and children and hope that no one catches you, or your loved ones. Again, if you decide to run would you like to have a gun with you?
lynch mob for a meticulous and professional criminal investigation leading to a fair and open trial.
Actually, the police do little to stop real crime (i'm not talking speeding tickets here i'm talking robberies, assault, murder, etc.). They are
little more than glorified paper pushers labeled as a deterrent. Basically you have to commit murder before any investigative part of the police
force is brought in. The local police where I live, always give the lame excuse that they are undermanned (even though there is like 1 cop per
100 people in the city). Its more like they are to busy enforcing traffic violations and petty civil issues (loud music, arresting people who haven't
paid their late tickets etc.) to do anything except show up and write an incident report when a real crime occurs.
I am apparently one of the few people who doesn't take the "we need more police" line seriously. More police != lower crime rate. Even
though that is usually the reason given to hire more. Instead I see 50 cops standing on street corners "showing presence" in groups of three or
so on a friday night when I go downtown to drink. Since, the town I live in is pretty laid back its rare to actually see them doing anything. Most
of the 'disturbances' probably occur in the bars which already have hired security there to check id's and deal with such problems.
Basically what i'm getting at, is you probably have a better chance of stopping crime if nearly everyone carried a gun. Effectively, you have
a 99% of the population as a police force. Instead of the first instinct being "call the police!" the first instinct should be "lets go stop that!" Five
to ten minutes later when the police show up there is a good chance that the burglar has run off with a few valuable things, the rapist has
finished up and ran away, or the murderer is half way across town.
Acually, it looks like it might be getting some lift from the body (ie lifting body). It could also apply to the big engine, small plane theory. Which says given enough thrust anything will fly. For example, the shuttle. I seriously doubt the second given its speed but I don't know what its operating limits are. It might require 275 knots to take off and have a max speed of 300..
You can get a cheap one for the price of a medium cost big screen TV. I can tell you a 10' wide screen (or whatever the wall size i'm using right now is) at 10 feet away is just as impressive as sitting in a theater. I have the additional advantage of lying down while watching movies and drinking beer.
I was reading their page and had this thought exactly.
The Large RealLike is based on the 'average' male penis. With our data we have gathered from Venus 2000 users we know what 'average' really is! It even has all the bumps and ridges of the real thing.I bet they have a larger more accuate sample size than most 'science' projects... Only problem is that they don't have the dimensions on the web page. LOL
That is pretty funny. It gives me a lot of confidence about the OS/software! Think about how many bugs you can't see if there is a glaring one on the example screen shot!
You are correct, I was going to point this out myself. Every 'RISC' arch I've used (even the ARM) has some save a group of registers instruction. But...!!!! There is a cost. Most of these instructions take many cycles to execute, so they just as well could be 10+ instructions. Latency is latency. The real savings is in code density. The real cost is in processor complexity. Besides the fact that this instruction and a couple others usually add an extra decode stage which breaks the 'Complex' instruction into more fundamental simple instructions. There is an exception handling issue. What happens if the instruction causes an exception (page fault,or an interrupt fires) half way through execution of the instruction? In particuar for load multiple when the instruction overwrites the register which contains the source address (diffrent PPC/POWER's handle this diffrently)? Ach ich,ugly problem, all to save a few instructions back when memory was expensive.
Oh, someone forgot to tell you that cache size is only 1/2 of the equation. The other is cache latency. A basic equation from comp-arch is that the sum of each cache/memory level's latency*hitrate gives the effective latency of the memory system.
This is great, and a first order analysis concludes that you want a really big, really fast cache. The only problem is that the bigger the cache the longer (in real time) it takes to fetch a row of data. The second part of the problem is that the processor has a fixed number of cycles (directly computable from the fetch->execute stage count) of latency it can tolerate. As the cycle times of the processor get faster (higher GHz) the amount of real time tolerances gets smaller. This means that if your processor can only tolerate a 2 cycle load to use time, then you should try really hard to get a L1 that can satisfy this. So, in this example 2 times the cycle time is the max time that the cache should have as a fetch time. Then its easy, you build the bigest cache that you can affort which can also satisfy this time requirement. Then because the L1 probably doesn't have a particularly good hitrate you repeate the process for a L2 with a slightly higher hitrate and a slightly slower latency. Contine adding cache layers until you either run out of money or you get an acceptable memory latency.
A second order analysis also includes looking at real life application hit rates and patterns. Then taking that data and using it to help make your decisions about cache size and latency. The intel engineers arn't idiots (nor are the ones at AMD, IBM etc) there is a real reason the cache is the size it is. If it didn't cost anything to double the L1 in either performace or money then you can be sure that any given processor would have 2x as much L1. Simple 0 order analysis (my cache/clockrate/dick is bigger) rarely tells even 10% of the story.
The ARM is a cute little arch, the only problem is that EVERY instruction is conditional. At first this seems like it might make for some really nice optimizations. But its a lot harder than you think (the instruction cache cannot just dump instructions, because it has to know what the current state of the processor is, this means that all instructions which affect the condition codes have to retire before decisions about which instructions can be executed are made). When I started thinking about how I would design an OO superscalar version it started to give me a real headache. Eventually I realized about the only way (I could think of, maybe there is a better way) would be to have some kind of in order conditional retire stage near the end of the pipeline. This would allow the processor to run at decent speeds as long as the code was very careful to rarely use the conditional execution, since it would effectivly serialize the instruction stream. The 'Always' execute instructions could retire out of order as long as there was enough distance between them and the condition changing/condition dependent instructions.
All this is to say, the ARM is a nice arch for low speed, low power devices. Really high speed versions might be pretty hard to get right. Intel's Xscale is like this, everything considered, it's IPC is pretty bad.Check out this article and the link it has to DDJ about the reason why people use VB even though its really ugly. Hint it has to do with how productive the _TOOL_ is not the language or its libraries.
Accually, you desperatly need to take a look at Kylix/Delphi/BCB from borland. Delphi is basically a cleaner VB. Right now there is a Linux port called Kylix which pretty much allows cross platform gui development. Of course it only runs on Linux/Windows, on the other hand I guarantee you will like it more than the assortment of other cross platform GUI toolkits like wxWindows & QT. Part of the VB advantage is the integrated enviroment with the way you just drop components, changes a couple properties, click on their events a write a couple lines of code and call the application complete. QT's designer is getting this way, but right now It doesn't have the component support the professional version of Delphi/BCB/Kylix have or the simple COM/ActiveX/etc target and use abilities that VB & Delphi have. I've got a small collection of 'demos' I show people from memory who have never seen what an eviroment like VB/Delphi can do. You know the kind, drop the database table component on a form, create a table with a key and a text field, tie the text field to a browser, add a couple lines a HTML into a few fields and demonstrate a couple cute tricks, or drop a scanner ActiveX (one of my development machines has a scanner) component on a form, tie it to a graphics box, write a couple lines of code tied to a button to run a RGB channel inversion filter or something simple like that.. It seems to amaze my C friends. Especially when I have one of those smooth days and do it all in under a minuite.
Ah, yes, I remember my forth work. Don't knock it, just because you don't understand it. It is a strange language. On the other hand it teaches some useful concepts, sort of like using an old reverse polish HP calculator for a year. In Forth in order to get anything reasonable done you have to break your problem up into little tiny self contained pieces. I think the resultant mindset coupled with modern component OO development helps to generate more maintainable code. People stop writing these huge do everything classes in C++/Java/etc. Instead you get these small well defined mini components.
As many other people have pointed out only a very narrow subset of applications will accually see a benifit from moving to 64-bit. Database are one of them, but we arn't talking about databases we are talking about the backend logic driving them. I suspect that there arn't many systems running today that will see a huge benifit from moving to 64-bit that arn't already running on a Sun/AIX/HPUX/etc box.
Secondly, I don't see how Java solves the problem of 3rd party vendors not being on the ball. If your database vendor thinks that the 'C' libraries are more important than the java drivers it makes the problem even worse. It seems the PHB factor is what drives this.
C# doesn't support clustering, distributed transactions, nor the object persistence that J2EE supports. Do you fully understand how much effort it would take for you to write a security system and distributed transactions for your entire enterprise? How about optimization of this system?
Correct C# (c/C++/most other languages) doesn't support these features. Its supported by the enviroment, in the case of C# by .NET. Personally I find old M$ technologies like DCOM/COM+/MS Transact to be more advanced than the J2EE support. Most of this stuff has been around forever (ever use an AS400?), in many cases its easier to use than the Java version. In others its a pain in the rear. Which is sort of my original point, that Java doesn't appear to be the best framework when compared with assorted other techologies. When compared to straight C it will win, this is primarly a function of the C minset forcing everything to be explicit. Besides a lot of this isn't a particularly big deal because the database backend will guarantee a certain level of tranactional consistancy. Ebay isn't as tight as you think either, this is a function of the fact that in the end all that matters is who is the highest bidder or in the event of a tie who placed the bid first. Just as long as consitancy is maintained all kinds of 'bad' things can happen. I've accually seen "you have won this item" screens from ebay on things I placed a bid on seconds before it closed, only to have it not be true because some other sniper managed to get a bid in after mine but before the auction closed.
This sounds nice but, does it really work that way? How often will a large company migrate their servers running a custom application from
one platform to another without bringing in someone to test and verify the system? Is the savings every few years worth the extra development
cost? In the past, by the time the system needed 'migration' rather than upgrading, it was time for a completely new application. Companies
migrated from the mainframes and minicomputers of the early 80's not because the couldn't handle the business anymore, but because it cost to
much to maintain the old hardware or the old business paradigm the software was written for was outdated. In some cases they updated
because it was cheaper to train someone to use a GUI application than the old TTY one. In 10 years will it really matter if you can migrate
your business backend? Will you want to?
Finally, Java runs well on *nix, and *nix is THE choice for big, serious sites. Sun makes Solaris, and Sun makes Java; that's all that needs to be said about that.
This sounds like my last statment, the real reason for using J2EE is to avoid M$. The middle tiers apparently arn't particulary performace intensive. Combined with the fact that companies like IBM make enterprise level PC servers means there really isn't a hardware reason. (There are dozens of companies making hot swap/failover M$ solutions too.) After the sun fiasco with the processor cache bugs causing random data corruption, and the coverup, I lost all my trust in them. To a certain extent the other Unix vendors as well. For all the talk about how closed the PC is, it seems far more open than the Unix vendors. Christ, I can't even access the HP user to user support boards without proving I have a machine under warantee or a support contract. I am now applying a basdardized Open Source theorem to my hardware. 'Millions of users make the bugs shallow and hard to cover up.'
Ok, something i've never quite understood. What is the benefit of Java on the server? It sort of made sense on the client even though most /., and ignoring the M$ hype about how much faster it is, it does a
companies have standard client configurations. I fail to see any advantage on the server. It seems to me that when installing / designing a back
end to a n-tier system the ability to be cross platform doesn't buy you much. The servers are specified to match the application. Java's
'standard' API's for database manipulation seem to come at the cost of performance. Yes, i've heard all the arguments about java
performance, but lets face it highly performance critical systems simply cannot be tuned as easily when you have a JVM between you and the
hardware and a set of generic libraries between you and the database, communications etc interface. So, lets assume that the applications don't
really need the performance. It then comes down to the question of whether or not Java and friends provide sufficiently high level abstractions
to ease development costs. Again, I simply don't find the java tool kits sufficiently better than assorted 3rd party system, even ones not
designed for building middle tier systems. Take Delphi for instance, the built in database manipulation components and its ability to handle
distributed systems, aren't really its strong point (building front ends) but its secondary support in the enterprise versions seems better than
J2EE. Then there are M$ offerings like C#.net. Admittedly a dirty word on
damn good job at enterprise backends.
In the end it seems to me that (especially here on /.) J2EE's strongest benefit is that you can build a system without involving M$. The
negative is that it seems to cost more, particularly for development.