(B) think Windows is so much better (client-side and often server-side!) than both of them... Windows will probably continue to be stuffed down everyone's throats by a majority of uninformed users and managers.
Well, here goes more karma.
I don't know to many people who are both Unix/linux and Windows users/programmers. On the other hand a know a lot of Linux/Unix people who are absolulty convinced that their platform is better, and I know a lot of Windows users who are very intelengent, and are currious about linux. In particular the Linux/UNIX people are completly clueless about windows, some haven't accually used a windows box since W95. Yet these same people will tell you all day long how much better unix is. I have been programming on Linux/Solaris/HPUX/AIX and every version of windows since the DOS/Win3.0 days. I know a lot about the internals of both Windows and Linux (you will find my name is a number of change logs including the kernel). When I see these/. discussions I laugh out loud sometimes at the complete ignorance of 99% of the posters. I chuckle to see someone complaining about some windows misfeature that has been default disabled for 3 years. Hidden in a reply is some 'troll' who is pointing this out. Yet, you _NEVER_ hear about the Linux problems. Take for example the ext3 inode overflow problem that redhat 8 shipped with. I lost a filesystem because of that bug. It took exactly 30 seconds to reproduce with a copy of bash. Yet, it existed in the kernel for something like 8 revisions. Where are all the articles about how little testing the kernel gets before its released? I like linux because its 'open' and I can fix any bugs, I don't like linux because I spend all my time fixing the problems rather than getting my problem solved. In that regard, I like windows because its works really well. I used to hate M$, the more I learn about their system the more respect I have for them. I've done device driver developement for windows. I also learned that the kernel is a 100x better design than anything any of the other major vendors are shipping. The API while old does all kinds of things that make an application developers job easier. The 3rd party tools are amazing. I find maybe one bug every couple of years in windows or the tool chain I use. Under linux I find a GCC problem every few months, the kernel will crash, or some application simply won't work. Were I now work we have spent more $ on Linux than on Windows this year. The last company I worked for used linux as the primary development server. That box didn't crash to much but we spent an amazing amount of money keeping it working. There was always some DHCP, bind, samba, or qmail problem.
Before I write a book here, I would like to close by saying. Don't say someone is uninformed simply because they like windows. Windows currently has something that is infinitly valuable. There are millions of users out there testing it everyday in a million diffrent ways. The likelyhood that someone hasn't already tried doing something similar to what your trying is pretty low. Because of this I can reasonably expect that whatever i'm trying to do will accually work.
I used OS/2 for a while, but my sound card didn't work because the vendor only made Windows drivers, yet it worked in Linux because some guy (or a few guys) had soundcards with the same chipset, so they figured it out and wrote a driver. In a closed system, if you don't have vendor support, then you're sunk. In an open system, at least you'll have a chance.
There isn't any reason that the same person who reverse engineered the sound card couldn't have written an OS/2 driver. This whole argument is bugus. It all comes down to demand and modivation. You also have to view this from a HW vendors perspective. When they make a product they need to make it as cheaply as possible to maximize profit while protecting their investment. If they have the resources to make 1 driver then they will make a driver for the product with the largest market share. Then open the driver source/HW doc's you say.. The only problem with this is that often times what makes one vendors product better than another vendors product is something in the driver package.
Err. You must have a good supply of magic pixie dust, because I work with considerably less than 500 NT/2000 machines (no XP yet) and I see system crashes day in, day out. From laptops bluescreening on wake-up from sleep mode, to explorer.exe hangs. My NT boxen had a nasty habit of surviving 7-14 days of moderate work before slowing down to molasses and poping a few VxDs. Usually, the driver developers use a diffrent extension usually.sys
Maybe its not windows, but rather something someone has done to them... Maybe someone ignorant.. I might also point out that NT boxes don't generaly use VxD's, because that is the driver model for 9x boxes. NT/2k/xp use a diffrent driver model. If your having crashes, start by only installing signed drivers. That should make 99+% of the crashes go away. I've made it a personal goal to know why my 2k boxes crash. Every single time so far its been a driver problem. Updating the driver (or in some cases the hardware) has fixed the problem. My home box is a 3 year old AMD, thats been running 2k, and its crashed once! And that turned out to be a bug in an old unsighed the GForce driver, irritated when I installed WarcraftIII. Updating the driver solved the problem. I've accually seen (and own) windows boxes that have never crashed.
Linux 2.4 on the other hand is an entirly diffrent story. Every time I stress it it fails. Few oops but lots of corrupted file systems (just look at the change log for ext3 or the VMM... christ), deadlocks. Modules that crash and the machine slowly falls down around them. Not to many oops but enought that I'm tired of them. I've got linux 2.2 boxes with uptimes counted in the years. Netcraft was tracking system uptimes for a while, i'm not still if they still are but last I checked the w2k boxes had better uptimes than anything but the BSD boxes.
Re:I don't know what to do - really - crashdump?
on
Linux v2.6 Begins Testing
·
· Score: 3, Insightful
I thought 2.6 was suppose to have crashdump support? If not, that's to bad, because often that is what is required to fix problems in the real world. Often the technical person isn't the same person who is using the machine. There needs to be a way for the technical person to figure out what went wrong after the fact. OOP's are about as useful as the BSOD data. Plus, unless its a repeatable problem usually by the time the machine crashes its a little to late to run out and hook up a serial console.
high end Intel chips have supported more then 4 gigs for quite a while, using the same funky segments+offsets system they used back in the 286 days to allow them to access more then 64k.
First the 8086 could access 1Meg using a 20 bit overlapping segment+offset system where the segment registers were 16 bits and the offset address was 16 bits. This was done by shifting the segment register left by 4 bits and adding it to the offset to produce a 20 bit address. It wasn't bad except that 'OS's from the time didnt make sure that the bottom 12 bits of the segment register were clear. This allowed all kinds of ugly hacks and workarounds. The 286 extended it to 16 megs (24 bits) by introducing segment selectors in protected mode. The offset register was still 16 bits same as all the other x86's at the time. Selectors now had base addresses which selected the base address which was added to the address offset.
Finally the 386 showed up and extended the offset address to 32-bits and extended the segment selectors to be capable of having a full 4G base register offset using a 4k granularity in protected mode. This 4k was important because the 386 introduced paging using 4k pages. The problem was that the maximum linear address space that a segment could exist in was 4G. This matched the physical address space limitation. This 4G linear address limitation meant that everytime a task switch happened the TLB had to be flushed. Which is another discussion..
Eventually the Ppro was released, with it came the idea of physical address spaces greater than 4G. It was the first x86 processor to support PAE (Page Address Extensions, if your really interrested you might also look at PSE, page size extensions) which extended the physical address space to 36 bits where it has been until the x86-64. The only problem is that Intel left the linear address range (the base address that a selector could be, see section 3.8 of the P4 sys programmers guide) limited to 32 bits. This kept people from playing the multiple segments pointing at diffrent address ranges games that were played with the 8086. It also meant that any one instant it was impossible to accually access more than 4G. In order to do this the page tables or the page directory pointer has to be played with (again requiring a TLB flush, or fancy page fill algorithms). Its basically a banked system similar to those used on Apple ]['s and the like where the linear address space can have windows into a larger physical address space.
NT/W2k/Xp/2003 machines with/3g in the boot.ini boot description will pop up the dialog. This is because the kernel is split 3:1 in that case.
I find it ammusing that you can remember the parameters for the WinMain() and MessageBox() (and are hence a API programmer rather than MFC or some other evil abstraction layer:>) but that you didn't know about the kernel split option.
powerful political lobby to fight off the lies of the IEEE
I don't know where you got the idea that the IEEE lied about the tech worker shortage. In fact they activly lobied against the H1B's claiming that there were plenty of older EE's that could be cheaply retrained.
IEEE-USA and other organizations representing engineers, computer scientists and health care providers opposed enactment of the new law on the grounds that IT worker shortage claims were overstated and because of concerns about the limited applicability of the worker safeguards.
This is more what I would expect, but maybe I did something wrong, instead of hard coding the number I passed it from the command line, where I convert it from the string to an int then pass it to your routine. After the recursive function returns I then convert the value back to a string and print it out.
You forgot two of the most elegant things the II had going for it.
The graphics system has incredibly simplistic hardware that simply set the composite color burst timings based on the a single bit shift of the video memory. This removed the complicated timing and DA conversions that other early color systems required. Of course it made it a pain to set any given pixel to a specified color, or even draw a line (the video memory wasn't mapped line for line to the screen for timing reasons). It also had some interesting side effects like leaving a couple of unused bytes at the beginning and end of each line which were scanned during the horizontal refresh allowed the programmer to 'hide' information in the video buffer. Eventually with the release of the 80 column card, the graphics system was increased to 16 colors and the horizontal resolution was doubled. My undestanding was that this was completly accidental and discovered only after the card had been on the market for a couple of months.
The other cool thing you sort of touched on was the soft sectored disks. Most disk drives of the time cost a lot of money because they also had complicated timing and encoding logic built onto them as well as sensors for detecting head location and where in the spin the disk was. Some history:The problem with magnetic media (and some communications mechanisms etc.) is you cannot tell were the bits start and stop so you need tight timing, or an encoding scheme which guarantees that no more than a certain number of off or on bits are adjacent. The disk drives for the II didn't have any head or disk position sensors, nor did they have encoding or timing logic. This was all offloaded to the software in the ROM's which encoded the bytes (using 4 by 6 encoding if I remember correctly) wrote the sectoring information (some series of bit patterns guaranteed to be unique with the encoding scheme and guaranteed to allow the software to detect where a byte started) and everything else related to managing the disk drives. This allowed the II disks to have some seriously ugly copy protection schemes (writing data between the tracks, because a track was actually 4 pulses of the stepper motor, spiral tracks, tracks with funny sectoring, funny encoding schemes the list goes on.) Not only that but since you couldn't tell where on the disk you were until you read the sector information, and not all the disks were sectored the same the ROM would basically pulse a full stroke to the stepper motor to locate the first track to boot the machine. This is what that really bad clunky / grinding noise is when the machine is first powered on. Another little trick was that the amount of data you could fit on the disk was related to how fast the disk was spinning (actually this is true of any disk to a certain extent). The software could correct for small imperfections in the rotational speed, but since the on/off timing of the head was directly controlled you needed to adjust the speed the disks spun at for optimum data consistency. Hence those little screw drivers that came with some models, and the disk tune utilities which would show you how fast the disk was spinning while you turned the adjustment on the drive. In the long run it turned out to be an advantage to have such low level control of the disk drive since various pieces of software were written to read other computers disk formats.
He he he, I thought about this a couple of years ago. At this point though, the new ARM based palms should be able to emulate a IIe in software at about 10x the speed of the original machine. Hmm sounds looks a good project for a weekend. Port one of the II emulators to palmos. Of course a native hardware based apple II would probably consume about.001% the power of a new palm device.
Which is interesting because its probably not there for you. Its probably there to cover their butts because the original 'transfer' may have occurred when they sold the license to your computer manufacturer, which used up the free turn when they sold it to you.
I have used a number of trinitron monitors. Until recently they had a lot better color than the invar shadow mask monitors. On the other hand I have yet to have accually used one of the large (>19") FD Trinitron's that after a month or so I didn't have to reconverge every morning. I don't know why but every single one I've seen recently couldn't keep the convergence for more than a few hours. Plus the controls on most of them don't allow individual color gun control (hence you cannot ever get all three in exactly the same spot, generaly one stays fixed and the other two move right and left with respect to the stationary one. This means that you can get two perfectly converged on each other but not the stationary one), and with the bigger ones the screen/top/bottom controls simply arn't precise enough to get the whole screen converged at once.
So yes, the old trinitrons had better color saturation than the old invar monitors but the color on the new invars are just as good and they are significantly sharper. Personally I am using a monitor with a Samsung tube in it, I love it! Sharpest thing I have ever owned.
Another good book for technique is Mark Bittman's How to Cook Everything. I've learned a lot from that book. Its also pretty easy to find. So just drive to your local mom and pop bookstore and have them order it if they don't stock it.
Support for large major/minor configurations. For example this translates to being able to handle more than 256 devices on a SAN. Hot Plug PCI & Io drawers that work. Capacity on demand across virtual partitions allows processor/RAM to appear disappear from a virtual partition. A journaled file system that supports dynamic expansion across LV's. Mixed 32-bit and 64-bit applications running on the same hardware under either a 32-bit or 64-bit kernel. A built in kernel debugger that doesn't suck.
This just off the top of my head. Most of these features like the the JFS/LVM stuff has been there for years.
To a certain extent programs like purify and bounds checker do automatic program debugging. BC will check for all kinds of runtime errors. Coupled with tight coding standards enforced by a lint like tool of your choosing a _LOT_ of bugs will be easily isolated automatically. When you combine these tools with a code coverage utility, a decent set of unit tests, a test utilty that can fail system and library calls you will discover a the bug count in released code will go down to nearly 0. Finding these bugs in developement is a lot easier that trying to do it with a core dump from the customers site. Take it from me I've worked for companies that released software where bugs that cause crashes, lost data etc were simply not acceptable.
People complaining about the debuggers themselves missing functionality are complaining because their code is either to poor to isolate the bug when it happens (causing it to propigate into areas where the bugs arn't ovious), or they simply arn't using all the tools avialable to them. Don't underestimate how useful enforced coding guidelines can be for writing bugfree code. There are whole classes of bugs that can be caught by a lint, but will result in hours of debugging. Variables that never get initialized are the perfect example.
I've been thinking about this for a while. The trick would be to put a trojan in a real game. When the trojan activates, it exploits some security hole in the Xbox OS to gain full control and then run a boot loader. That way you buy the game for the price M$ charges for the licence fee, hold down some button, which activates the trojan/boot loader and then swap in a CD for your favorite OS.
A month or so ago I noticed that my dual 550 linux box could surf faster than my 1.5Ghz AMD W2k box. Instead of being a linux zelot and claiming that linux was _WAY_ faster I looked into why IE was being so slow.
The reason turned out to be a 200+ meg IE disk cache that was full of 1k files. Everytime I went to load a new page it checked for cached items. Even with the directory structure cached, a page with 50+ images apparently was linearly scanning the directory structure 50+ times looking for a matching filename. Deleting the IE cache data, and lowering the cache size to something like 5 megs, was like someone unhooked a 2 ton trailer from my little sports car. It was truely amazing.
BTW: I also know how to add new zones to IE, so if anyone is interrested just ask I will provide the URL or details.
The CDC collects the best statsitics on what everyone in the US dies from. These statistics will quickly show that your chances of dying from a gun are extreemly low. Combined with the fact that in 1999 57% of the gun related deaths were suicides makes it even less likely that you will be unintentially killed by a gun.
Re:Just to remind people why more bits is good..
on
AMD's 64-bit Plot
·
· Score: 2
Miraculously, someone at Intel stowed the x86 crackpipe, preventing some sort of segmented/overlay nightmare like the one you describe.
No, its just the rebirth of an even more evil concept, "bank switched memory" because that is effectivly what has to happen to use more than 4 gigs at a time. Look at the W2k "Address Window Extensions" which allow more than 4gb access in a manner similar to the old DOS EMS extension. In order to support this they have to be constantly fsking with the page tables, which results in lots of TLB flushes, and on SMP boxes IPI's. In the end its really slow slow slow! Plus you end up supporting the thing as though you have a bunch of 4k segments.
So please no more of the "wow, decoding music with a 33Mhz processor would never work," "wow, I can hold two songs in my 8MB of RAM," etc., etc. comments. You are right, the old Palms WILL NEVER play music files; it is simply infeasible.
First, there are mp3 addon's for old Handsprings and Palm's for example . I'm sure there are smaller ones too.
Secondly, i'm not convinced that the base palm cannot decode mp3's the small memory footprint on the older palm's may be a problem, but I suspect that a mono 128k bit signal can probably be decoded on the 33mhz models. Look at Mayplay for an example of a mp3 decoder from the time when mp3s were just getting popular. I remember running it on a 486DX2-66 without any problems at all. I seem to remember it chewing up all my CPU time, but being able to decode stereo 128kbit mp3's.
I canceled after a few months, but I count close to 12,000 mp3's I downloaded from them. They never sent me a letter or anything.
I was running a 'script' of course. But I do listen to most of it. I got that all in one or two days spaced over maybe 4 months. Then after 3 months of completly forgetting to download more (while I caught up on the stuff I had already downloaded) I decided to cancel since I was just paying $15 for a service I wasn't using.
On the other hand the 2k mp3's seems a little low, I would imagine something closer to 4k would be a reasonable "unlimited" cap since that might be the behavior of a user who is using them like a 'streaming' service while at work and home. Of course the 2k max a month makes sense. Users who want more should buy two subscriptions. Putting a number on "unlimited" like "up to 2k mp3's a month" probably would make more than a few users feel like they should get their full allotment of 2k mp3's each month.
can be described as a small organizer/calculator. I use it as a graphing calculator, to store phone numbers, quick notes to myself, gate codes at friends apartments etc.. I also use it to read books from Project Gutenberg or sometimes to check out the news/weather.
Well then you ask, why is it better than a paper organizer with a book and calculator? Two reasons, size and the ability to back it up! I use the m500 solely based on the fact that it is the smallest palm I can find. Its thinner than any of the other ones (including the m505/m515) and marginally larger (wxh) than some of the newer sony's and tungston's. The thickness is the most important dimension because I have big pockets but I don't like it sticking out. Anyway, it can also be backed up which is good since everyone looses those little pieces of paper they write things down on, the whole organizer, and every couple of years even the nice leather ones look crappy and need to be replaced. So, instead of copying a bunch of crap, I can just pick up a new pda and sync it with my old data.
Crashes? I think i've seen two of those, both related to a little application I wrote. I don't stick a lot of software on it, so I guess I've been lucky to use mostly bug free stuff..
Its definitly a tool for the geeks though, most normal people i've seen using them are just using the keyboard mapping. Hopefully at some point palm will do the CE thing and provide a switchable input area. For a while a lot of managment types were using them but they seem to have given up on the whole idea. These people would rather just pick up the phone and call their personal slave to remind them of appointments, phone numbers, etc. So for those people a PDA was basically just a status symbol until they discovered that most PDA's are hard to carry without a bulge.
I think I saw that one.. They were using standard solid fuel model rocket engines. Those things just tend to work (unless you make them yourself!). They also have a high initial impulse which gets them traveling in the right direction quickly making the tail fins functional. Basically, they just built big toy rockets. This beasty is an early prototype for a rocket that will fly into space. There is quite a diffrence.
Slashdot Mirror
Well, here goes more karma.
I don't know to many people who are both Unix/linux and Windows users/programmers. On the other hand a know a lot of Linux/Unix people who are absolulty convinced that their platform is better, and I know a lot of Windows users who are very intelengent, and are currious about linux. In particular the Linux/UNIX people are completly clueless about windows, some haven't accually used a windows box since W95. Yet these same people will tell you all day long how much better unix is. I have been programming on Linux/Solaris/HPUX/AIX and every version of windows since the DOS/Win3.0 days. I know a lot about the internals of both Windows and Linux (you will find my name is a number of change logs including the kernel). When I see these /. discussions I laugh out loud sometimes at the complete ignorance of 99% of the posters. I chuckle to see someone complaining about some windows misfeature that has been default disabled for 3 years. Hidden in a reply is some 'troll' who is pointing this out. Yet, you _NEVER_ hear about the Linux problems. Take for example the ext3 inode overflow problem that redhat 8 shipped with. I lost a filesystem because of that bug. It took exactly 30 seconds to reproduce with a copy of bash. Yet, it existed in the kernel for something like 8 revisions. Where are all the articles about how little testing the kernel gets before its released? I like linux because its 'open' and I can fix any bugs, I don't like linux because I spend all my time fixing the problems rather than getting my problem solved. In that regard, I like windows because its works really well. I used to hate M$, the more I learn about their system the more respect I have for them. I've done device driver developement for windows. I also learned that the kernel is a 100x better design than anything any of the other major vendors are shipping. The API while old does all kinds of things that make an application developers job easier. The 3rd party tools are amazing. I find maybe one bug every couple of years in windows or the tool chain I use. Under linux I find a GCC problem every few months, the kernel will crash, or some application simply won't work. Were I now work we have spent more $ on Linux than on Windows this year. The last company I worked for used linux as the primary development server. That box didn't crash to much but we spent an amazing amount of money keeping it working. There was always some DHCP, bind, samba, or qmail problem.
Before I write a book here, I would like to close by saying. Don't say someone is uninformed simply because they like windows. Windows currently has something that is infinitly valuable. There are millions of users out there testing it everyday in a million diffrent ways. The likelyhood that someone hasn't already tried doing something similar to what your trying is pretty low. Because of this I can reasonably expect that whatever i'm trying to do will accually work.
There isn't any reason that the same person who reverse engineered the sound card couldn't have written an OS/2 driver. This whole argument is bugus. It all comes down to demand and modivation. You also have to view this from a HW vendors perspective. When they make a product they need to make it as cheaply as possible to maximize profit while protecting their investment. If they have the resources to make 1 driver then they will make a driver for the product with the largest market share. Then open the driver source/HW doc's you say.. The only problem with this is that often times what makes one vendors product better than another vendors product is something in the driver package.
Maybe its not windows, but rather something someone has done to them... Maybe someone ignorant.. I might also point out that NT boxes don't generaly use VxD's, because that is the driver model for 9x boxes. NT/2k/xp use a diffrent driver model. If your having crashes, start by only installing signed drivers. That should make 99+% of the crashes go away. I've made it a personal goal to know why my 2k boxes crash. Every single time so far its been a driver problem. Updating the driver (or in some cases the hardware) has fixed the problem. My home box is a 3 year old AMD, thats been running 2k, and its crashed once! And that turned out to be a bug in an old unsighed the GForce driver, irritated when I installed WarcraftIII. Updating the driver solved the problem. I've accually seen (and own) windows boxes that have never crashed.
Linux 2.4 on the other hand is an entirly diffrent story. Every time I stress it it fails. Few oops but lots of corrupted file systems (just look at the change log for ext3 or the VMM... christ), deadlocks. Modules that crash and the machine slowly falls down around them. Not to many oops but enought that I'm tired of them. I've got linux 2.2 boxes with uptimes counted in the years. Netcraft was tracking system uptimes for a while, i'm not still if they still are but last I checked the w2k boxes had better uptimes than anything but the BSD boxes.
I thought 2.6 was suppose to have crashdump support? If not, that's to bad, because often that is what is required to fix problems in the real world. Often the technical person isn't the same person who is using the machine. There needs to be a way for the technical person to figure out what went wrong after the fact. OOP's are about as useful as the BSOD data. Plus, unless its a repeatable problem usually by the time the machine crashes its a little to late to run out and hook up a serial console.
First the 8086 could access 1Meg using a 20 bit overlapping segment+offset system where the segment registers were 16 bits and the offset address was 16 bits. This was done by shifting the segment register left by 4 bits and adding it to the offset to produce a 20 bit address. It wasn't bad except that 'OS's from the time didnt make sure that the bottom 12 bits of the segment register were clear. This allowed all kinds of ugly hacks and workarounds. The 286 extended it to 16 megs (24 bits) by introducing segment selectors in protected mode. The offset register was still 16 bits same as all the other x86's at the time. Selectors now had base addresses which selected the base address which was added to the address offset.
Finally the 386 showed up and extended the offset address to 32-bits and extended the segment selectors to be capable of having a full 4G base register offset using a 4k granularity in protected mode. This 4k was important because the 386 introduced paging using 4k pages. The problem was that the maximum linear address space that a segment could exist in was 4G. This matched the physical address space limitation. This 4G linear address limitation meant that everytime a task switch happened the TLB had to be flushed. Which is another discussion..
Eventually the Ppro was released, with it came the idea of physical address spaces greater than 4G. It was the first x86 processor to support PAE (Page Address Extensions, if your really interrested you might also look at PSE, page size extensions) which extended the physical address space to 36 bits where it has been until the x86-64. The only problem is that Intel left the linear address range (the base address that a selector could be, see section 3.8 of the P4 sys programmers guide) limited to 32 bits. This kept people from playing the multiple segments pointing at diffrent address ranges games that were played with the 8086. It also meant that any one instant it was impossible to accually access more than 4G. In order to do this the page tables or the page directory pointer has to be played with (again requiring a TLB flush, or fancy page fill algorithms). Its basically a banked system similar to those used on Apple ]['s and the like where the linear address space can have windows into a larger physical address space.
I've got a realitivly new RADAR/LIDAR detector and most of the hits I get in Texas/Austin area are still RADAR.
NT/W2k/Xp/2003 machines with /3g in the boot.ini boot description will pop up the dialog. This is because the kernel is split 3:1 in that case.
I find it ammusing that you can remember the parameters for the WinMain() and MessageBox() (and are hence a API programmer rather than MFC or some other evil abstraction layer :>) but that you didn't know about the kernel split option.
I don't know where you got the idea that the IEEE lied about the tech worker shortage. In fact they activly lobied against the H1B's claiming that there were plenty of older EE's that could be cheaply retrained.
IEEE-USA and other organizations representing engineers, computer
scientists and health care providers opposed enactment of the new law on
the grounds that IT worker shortage claims were overstated and because of
concerns about the limited applicability of the worker safeguards.
Ok, so i tried it on my dual 550 box and java is slower. What gives....
~ >time fibtest 45
fib 45 is 1134903170
70.19user 0.11system 1:10.94elapsed 99%CPU
~ >time java fibtest 45
fib 45 is 1134903170
111.58user 0.26system 1:52.77elapsed 99%CPU
Both were compiled without any switches..
This is more what I would expect, but maybe I did something wrong, instead of hard coding the number I passed it from the command line, where I convert it from the string to an int then pass it to your routine. After the recursive function returns I then convert the value back to a string and print it out.
Not quite what you are talking about.. but here it is anyway.
You forgot two of the most elegant things the II had going for it.
The graphics system has incredibly simplistic hardware that simply set the composite color burst timings based on the a single bit shift of the video memory. This removed the complicated timing and DA conversions that other early color systems required. Of course it made it a pain to set any given pixel to a specified color, or even draw a line (the video memory wasn't mapped line for line to the screen for timing reasons). It also had some interesting side effects like leaving a couple of unused bytes at the beginning and end of each line which were scanned during the horizontal refresh allowed the programmer to 'hide' information in the video buffer. Eventually with the release of the 80 column card, the graphics system was increased to 16 colors and the horizontal resolution was doubled. My undestanding was that this was completly accidental and discovered only after the card had been on the market for a couple of months.
The other cool thing you sort of touched on was the soft sectored disks. Most disk drives of the time cost a lot of money because they also had complicated timing and encoding logic built onto them as well as sensors for detecting head location and where in the spin the disk was. Some history:The problem with magnetic media (and some communications mechanisms etc.) is you cannot tell were the bits start and stop so you need tight timing, or an encoding scheme which guarantees that no more than a certain number of off or on bits are adjacent. The disk drives for the II didn't have any head or disk position sensors, nor did they have encoding or timing logic. This was all offloaded to the software in the ROM's which encoded the bytes (using 4 by 6 encoding if I remember correctly) wrote the sectoring information (some series of bit patterns guaranteed to be unique with the encoding scheme and guaranteed to allow the software to detect where a byte started) and everything else related to managing the disk drives. This allowed the II disks to have some seriously ugly copy protection schemes (writing data between the tracks, because a track was actually 4 pulses of the stepper motor, spiral tracks, tracks with funny sectoring, funny encoding schemes the list goes on.) Not only that but since you couldn't tell where on the disk you were until you read the sector information, and not all the disks were sectored the same the ROM would basically pulse a full stroke to the stepper motor to locate the first track to boot the machine. This is what that really bad clunky / grinding noise is when the machine is first powered on. Another little trick was that the amount of data you could fit on the disk was related to how fast the disk was spinning (actually this is true of any disk to a certain extent). The software could correct for small imperfections in the rotational speed, but since the on/off timing of the head was directly controlled you needed to adjust the speed the disks spun at for optimum data consistency. Hence those little screw drivers that came with some models, and the disk tune utilities which would show you how fast the disk was spinning while you turned the adjustment on the drive. In the long run it turned out to be an advantage to have such low level control of the disk drive since various pieces of software were written to read other computers disk formats.
He he he, I thought about this a couple of years ago. At this point though, the new ARM based palms should be able to emulate a IIe in software at about 10x the speed of the original machine. Hmm sounds looks a good project for a weekend. Port one of the II emulators to palmos. Of course a native hardware based apple II would probably consume about .001% the power of a new palm device.
Which is interesting because its probably not there for you. Its probably there to cover their butts because the original 'transfer' may have occurred when they sold the license to your computer manufacturer, which used up the free turn when they sold it to you.
I have used a number of trinitron monitors. Until recently they had a lot better color than the invar shadow mask monitors. On the other hand I have yet to have accually used one of the large (>19") FD Trinitron's that after a month or so I didn't have to reconverge every morning. I don't know why but every single one I've seen recently couldn't keep the convergence for more than a few hours. Plus the controls on most of them don't allow individual color gun control (hence you cannot ever get all three in exactly the same spot, generaly one stays fixed and the other two move right and left with respect to the stationary one. This means that you can get two perfectly converged on each other but not the stationary one), and with the bigger ones the screen/top/bottom controls simply arn't precise enough to get the whole screen converged at once.
So yes, the old trinitrons had better color saturation than the old invar monitors but the color on the new invars are just as good and they are significantly sharper. Personally I am using a monitor with a Samsung tube in it, I love it! Sharpest thing I have ever owned.
Another good book for technique is Mark Bittman's How to Cook Everything. I've learned a lot from that book. Its also pretty easy to find. So just drive to your local mom and pop bookstore and have them order it if they don't stock it.
Support for large major/minor configurations. For example this translates to being able to handle more than 256 devices on a SAN. Hot Plug PCI & Io drawers that work. Capacity on demand across virtual partitions allows processor/RAM to appear disappear from a virtual partition. A journaled file system that supports dynamic expansion across LV's. Mixed 32-bit and 64-bit applications running on the same hardware under either a 32-bit or 64-bit kernel. A built in kernel debugger that doesn't suck.
This just off the top of my head. Most of these features like the the JFS/LVM stuff has been there for years.
To a certain extent programs like purify and bounds checker do automatic program debugging. BC will check for all kinds of runtime errors. Coupled with tight coding standards enforced by a lint like tool of your choosing a _LOT_ of bugs will be easily isolated automatically. When you combine these tools with a code coverage utility, a decent set of unit tests, a test utilty that can fail system and library calls you will discover a the bug count in released code will go down to nearly 0. Finding these bugs in developement is a lot easier that trying to do it with a core dump from the customers site. Take it from me I've worked for companies that released software where bugs that cause crashes, lost data etc were simply not acceptable.
People complaining about the debuggers themselves missing functionality are complaining because their code is either to poor to isolate the bug when it happens (causing it to propigate into areas where the bugs arn't ovious), or they simply arn't using all the tools avialable to them. Don't underestimate how useful enforced coding guidelines can be for writing bugfree code. There are whole classes of bugs that can be caught by a lint, but will result in hours of debugging. Variables that never get initialized are the perfect example.
I've been thinking about this for a while. The trick would be to put a trojan in a real game. When the trojan activates, it exploits some security hole in the Xbox OS to gain full control and then run a boot loader. That way you buy the game for the price M$ charges for the licence fee, hold down some button, which activates the trojan/boot loader and then swap in a CD for your favorite OS.
A month or so ago I noticed that my dual 550 linux box could surf faster than my 1.5Ghz AMD W2k box. Instead of being a linux zelot and claiming that linux was _WAY_ faster I looked into why IE was being so slow.
The reason turned out to be a 200+ meg IE disk cache that was full of 1k files. Everytime I went to load a new page it checked for cached items. Even with the directory structure cached, a page with 50+ images apparently was linearly scanning the directory structure 50+ times looking for a matching filename. Deleting the IE cache data, and lowering the cache size to something like 5 megs, was like someone unhooked a 2 ton trailer from my little sports car. It was truely amazing.
BTW: I also know how to add new zones to IE, so if anyone is interrested just ask I will provide the URL or details.
The CDC collects the best statsitics on what everyone in the US dies from. These statistics will quickly show that your chances of dying from a gun are extreemly low. Combined with the fact that in 1999 57% of the gun related deaths were suicides makes it even less likely that you will be unintentially killed by a gun.
No, its just the rebirth of an even more evil concept, "bank switched memory" because that is effectivly what has to happen to use more than 4 gigs at a time. Look at the W2k "Address Window Extensions" which allow more than 4gb access in a manner similar to the old DOS EMS extension. In order to support this they have to be constantly fsking with the page tables, which results in lots of TLB flushes, and on SMP boxes IPI's. In the end its really slow slow slow! Plus you end up supporting the thing as though you have a bunch of 4k segments.
First, there are mp3 addon's for old Handsprings and Palm's for example . I'm sure there are smaller ones too.
Secondly, i'm not convinced that the base palm cannot decode mp3's the small memory footprint on the older palm's may be a problem, but I suspect that a mono 128k bit signal can probably be decoded on the 33mhz models. Look at Mayplay for an example of a mp3 decoder from the time when mp3s were just getting popular. I remember running it on a 486DX2-66 without any problems at all. I seem to remember it chewing up all my CPU time, but being able to decode stereo 128kbit mp3's.
I canceled after a few months, but I count close to 12,000 mp3's I downloaded from them. They never sent me a letter or anything.
I was running a 'script' of course. But I do listen to most of it. I got that all in one or two days spaced over maybe 4 months. Then after 3 months of completly forgetting to download more (while I caught up on the stuff I had already downloaded) I decided to cancel since I was just paying $15 for a service I wasn't using.
On the other hand the 2k mp3's seems a little low, I would imagine something closer to 4k would be a reasonable "unlimited" cap since that might be the behavior of a user who is using them like a 'streaming' service while at work and home. Of course the 2k max a month makes sense. Users who want more should buy two subscriptions. Putting a number on "unlimited" like "up to 2k mp3's a month" probably would make more than a few users feel like they should get their full allotment of 2k mp3's each month.can be described as a small organizer/calculator. I use it as a graphing calculator, to store phone numbers, quick notes to myself, gate codes at friends apartments etc.. I also use it to read books from Project Gutenberg or sometimes to check out the news/weather.
Well then you ask, why is it better than a paper organizer with a book and calculator? Two reasons, size and the ability to back it up! I use the m500 solely based on the fact that it is the smallest palm I can find. Its thinner than any of the other ones (including the m505/m515) and marginally larger (wxh) than some of the newer sony's and tungston's. The thickness is the most important dimension because I have big pockets but I don't like it sticking out. Anyway, it can also be backed up which is good since everyone looses those little pieces of paper they write things down on, the whole organizer, and every couple of years even the nice leather ones look crappy and need to be replaced. So, instead of copying a bunch of crap, I can just pick up a new pda and sync it with my old data.
Crashes? I think i've seen two of those, both related to a little application I wrote. I don't stick a lot of software on it, so I guess I've been lucky to use mostly bug free stuff..
Its definitly a tool for the geeks though, most normal people i've seen using them are just using the keyboard mapping. Hopefully at some point palm will do the CE thing and provide a switchable input area. For a while a lot of managment types were using them but they seem to have given up on the whole idea. These people would rather just pick up the phone and call their personal slave to remind them of appointments, phone numbers, etc. So for those people a PDA was basically just a status symbol until they discovered that most PDA's are hard to carry without a bulge.
I think I saw that one.. They were using standard solid fuel model rocket engines. Those things just tend to work (unless you make them yourself!). They also have a high initial impulse which gets them traveling in the right direction quickly making the tail fins functional. Basically, they just built big toy rockets. This beasty is an early prototype for a rocket that will fly into space. There is quite a diffrence.