So how does one separate the wheat from the chaff, the true stromatolites from the fakes?
One method is to examine the suspect rock with a microscope, looking for visual evidence of microorganisms. But as researchers who study ancient terrestrial rocks- and one notorious Martian meteorite - have discovered, it isn't all that easy to tell, just by looking at shapes, whether or not a microscopic blob in a rock was once alive.
So, what do they verify the gzip method against? Their guesses about the image origins? Does not look great from the methodology standpoint, eh?
I've recently implemented a SOAP interface to a database (as an Apache module written in Delphi 7). It crawled, albeit only until I replaced the standard Delphi native-to-SOAP translator with a custom one. The problem was that the standard translator:
1. Built a DOM-Tree from the native Delphi data structures.
2. Serialized the tree.
Since the resulting datasets were usually big, it was painfully slow, mostly because of allocation/deallocation of the tree nodes. Once I built an "on the fly" converter, the XML generation time fell below 10% of the database access time.
The point - perhaps it's not the protocol, but the inefficient implementations that slow things down? In the above case, replacing SOAP with a tightly packed binary protocol, would only (at best) speed things 10% up. On the other hand, if the client were a handheld, perhaps things would be indeed much slower on the client side because of the XML/SOAP issues.
Yes, they are maths (algorithmics) problems. But algorithmic background isn't enough to win this contest. You have to implement the algorithm you came up with and you have to implement it fast.
You have no time to think about the implementation details of your data structures. You've got to know the implementation of all the basic algorithms and data structures by heart - no time to debug your AVL implementation there.
Of course you've got to be a fast typist, or at least have one on the team.
These abilities don't automatically make you a good programmer, but can help you become one.
Just sticking an extra 32 lines on the address bus isn't going to work.
It isn't? There is a whole lot of processors whose address bus is wider than their data bus & ALU. Probably all of the 8-bit processors and most of the 16-bit ones.
Yea, some people need more than 4 gigs of memory per process. That's just not easy to do with 32bit.
Good point, but this only means that the address bus should be widened. I suppose that 32 bit data registers & ALU are still OK for most applications. If you need more than 32 bit, you are probably doing cryptography anyway, so even 64 bits are too short.
If you believe free software is good (I do)
And if you believe software reuse must come sometime (I do)
Then you cannot think that there will be a strong market for coders for ever - it just doesn't make sense.
Yes & yes, but no. Code reuse has its limits, so there will still be market for custom solutions. In fact, the market could even get bigger with FS - if a core application is free, the customers have more money for getting it customized.
I'm lucky to work for a company that does just that - custom solutions. We work in a commercial environment (various commercial DBMS-es + Delphi), customers get full source. Currently they are not licenced to redistribute, but even if they were, I doubt this would affect the company - first, they probably wouldn't anyway; second, the solutions fit for one customer wouldn't probably work for another.
Serial being serial, they only have 1 DATA pin. the other pins are used for control.
Parallel ports have 8 data out pins, 8 status pins which can be used for data in, and a few (3 IIRC) control pins.
So Parallel is easier because you don't have to decode the serial data (demultiplexing)
Yes, serial has only 1 data pin, but nobody said you cannot use control pins, like DTR for transmitting your data. Some cheaper UPSes use that trick to transmit their status back to the PC. Actually I remember a program that let you transmit more than the 115200 bps using the control pins to transmit data between 2 PCs.
Is learning one machine language equivilent enough that you can learn them all easily enough?
Mu.
The concepts from 8-bit processors, like instructions, registers and flags are still there and haven't changed much. Of course the new processors brought new concepts - virtual modes, paging, sophisticated memory protection schemes, interrupt hierarchies, numeric coprocessors, hinted jumps, various kinds of SIMD instructions and so on and so on.
On the other hand, most developers are pretty much separated from the processor - the operating system and the compiler are there to manage all of the above. Even if you want a super-optimized piece of code, it's a good idea to start by looking at the compiler output.
This is of course only true if you don't plan to write your own OS or a compiler.
What books WOULD you recommend, if this one sucks rocks?
I have only read the review, not the book, but judging from the review, "Peopleware : Productive Projects and Teams" by Tom Demarco & Timothy Lister could be recommended instead of this one. Focuses on people, not the process, the authors' assertions are well proven (Hm... Ok, well argumented) and it is fun to read. I'd write more, but I can't access the book right now.
Reed believes that as more and more of radio's basic signal-processing functions are defined in software, rather than etched into hardware, radios will be able to adapt as conditions change, even after they are in use. Reed sees a world of "polite" radios that will negotiate new conversational protocols and ask for assistance from their radio peers.
Echelon reportedly monitors phone numbers and voices, then uses satellite triangulation to locate the user.
Ok, the cell phone signal is strong enough to be decoded at the nearest base station - a mile or so away (Ok, let's round up to 5 miles). Lowest satellite orbit is about 100 miles. Signal power is inversely proportional to distance^3. So the satellite gets the signal about 8000 times weaker than the base station (plus equally strong signals from thousands of other cell phones, not to mention other RF sources). Can it really pick up the signal from a single phone?
I guess that you can pick up the signal amplified by the base station, but you can probably get the base station position by simpler means than satellite triangulation.
Why doesn't stuff of this nature happen more often? Why can't this same logic be applied (through different, although possibly similar means) to other Bad Things that happen on the internet? What could stop Adobe suing Russian hackers? What would put an end to bad patents? What could even stop the application of the DMCA? Large scale, cooperative denial of service (in this case denying to serve them, not flooding their lines) of the institutions which do these things.
Usenet UDP is specific:
1. Few parties involved - Usenet is much more hierarchical than the general Internet. Probably if less than 20 (my guess, it might be wrong) important parties agree on a UDP, it gets enforced. How many entities would have to boycott Adobe (or whoever) for them to actually feel it?
2. Clear and publicly defined "abuse". Spam, rogue cancels & supersedes. You don't get UDP'ed for being nasty to whales or pushing for bad legislation. This makes agreement easier, if not automatic.
Withouth the 2 above conditions, it ends in a parody: Bob from Smallville doesn't show his homepage to Adobe employees, Alice from Podunk drops all mail from Microsoft and the boycotted companies would laugh at this if they only knew that they are "boycotted".
Both LEDs and lasers are monochromatic light sources. Lasers have the additional advantage of producing a very coherent beam without additional optics, but LED + a few lenses gives just that. Strong LED is more likely to damage your vision than a weak laser. (As far as I remember, class 2 laser means "no permanent damage after staring at it for less than 20 minutes")
Does this mean that with their algorithm now publicly available, we're going to find more "googlebuster" sites finding ways to improve their rankings?
I don't think so. The patent is probably so broad, that it covers every searching algorithm that looks at hyperlinks, and that was publicly known a long time ago.
I would play it, but the user interface is too bloated. I'd like something like that:
You find yourself on an empty tile. Looking northwest you see a large chest. A grid bug approaches you from southwest. There's a curved wand 2 squares to the north.
>
Yes, killing opponents before they act probably plays a role here. I also guess that Saddam Hussein has never heard of "budget restrictions" "concerned taxpayers" and such. His budget might be several orders of magnitude smaller than the US budget, but he is practically free to spend all of this like he sees fit - and security is probably his top concern. Not to mention that instant death penalty for lack of security does wonders for guards' morale.
Another net mag closing its doors... where is micropayment that works and could help these alternative publications to survive?
Even with a working micropayments solution, "a well written & prosperous indy magazine" is an oxymoron, or at least a very unstable phenomenon. If they started raking money, they would probably change their writing to please more people and rake more money, eventually ending as Yet Another Barely Readable Magazine Trying To Please Everyone.
Slashdot Mirror
1. Built a DOM-Tree from the native Delphi data structures.
2. Serialized the tree.
Since the resulting datasets were usually big, it was painfully slow, mostly because of allocation/deallocation of the tree nodes. Once I built an "on the fly" converter, the XML generation time fell below 10% of the database access time.
The point - perhaps it's not the protocol, but the inefficient implementations that slow things down? In the above case, replacing SOAP with a tightly packed binary protocol, would only (at best) speed things 10% up. On the other hand, if the client were a handheld, perhaps things would be indeed much slower on the client side because of the XML/SOAP issues.
Developers! Developers! Developers!
You have no time to think about the implementation details of your data structures. You've got to know the implementation of all the basic algorithms and data structures by heart - no time to debug your AVL implementation there. Of course you've got to be a fast typist, or at least have one on the team.
These abilities don't automatically make you a good programmer, but can help you become one.
I could fit "you suck" or something equally insightful into one processor word. Other than that, I don't care. Do you?
I'm lucky to work for a company that does just that - custom solutions. We work in a commercial environment (various commercial DBMS-es + Delphi), customers get full source. Currently they are not licenced to redistribute, but even if they were, I doubt this would affect the company - first, they probably wouldn't anyway; second, the solutions fit for one customer wouldn't probably work for another.
Don't be a dickhead.
The concepts from 8-bit processors, like instructions, registers and flags are still there and haven't changed much. Of course the new processors brought new concepts - virtual modes, paging, sophisticated memory protection schemes, interrupt hierarchies, numeric coprocessors, hinted jumps, various kinds of SIMD instructions and so on and so on.
On the other hand, most developers are pretty much separated from the processor - the operating system and the compiler are there to manage all of the above. Even if you want a super-optimized piece of code, it's a good idea to start by looking at the compiler output.
This is of course only true if you don't plan to write your own OS or a compiler.
Radio's basic signal function defined in software? Sure, "Maximize your bandwidth with our new RadioBooster!!!" (at the cost of your neighbors).
While this guy might have a point - the current FCC policies on RF spectrum might be a bit outdated, I would be careful with deregulation here.
I guess that you can pick up the signal amplified by the base station, but you can probably get the base station position by simpler means than satellite triangulation.
1. Few parties involved - Usenet is much more hierarchical than the general Internet. Probably if less than 20 (my guess, it might be wrong) important parties agree on a UDP, it gets enforced. How many entities would have to boycott Adobe (or whoever) for them to actually feel it?
2. Clear and publicly defined "abuse". Spam, rogue cancels & supersedes. You don't get UDP'ed for being nasty to whales or pushing for bad legislation. This makes agreement easier, if not automatic.
Withouth the 2 above conditions, it ends in a parody: Bob from Smallville doesn't show his homepage to Adobe employees, Alice from Podunk drops all mail from Microsoft and the boycotted companies would laugh at this if they only knew that they are "boycotted".
... and I thought that "Adapting applications on the fly" was an article about hot-swappable modules!
You find yourself on an empty tile.
Looking northwest you see a large chest.
A grid bug approaches you from southwest.
There's a curved wand 2 squares to the north.
>
Yes, killing opponents before they act probably plays a role here. I also guess that Saddam Hussein has never heard of "budget restrictions" "concerned taxpayers" and such. His budget might be several orders of magnitude smaller than the US budget, but he is practically free to spend all of this like he sees fit - and security is probably his top concern. Not to mention that instant death penalty for lack of security does wonders for guards' morale.