However, in debugging, one must create tools. Event if these tools are as simple as:::OutputDebugStringW(wsz_request);
The difference between a readable and a non-readable protocol is that you can just log or snoop on the protocol stream directly with printf() etc and not have to write anything to decode it. Also your readable protocol is usually some form of text, so you can also immediately use any text handling tool at your disposal. Creating debugging routines costs extra time/money.
nevertheless a tool has been created.
You can look at it like that, but the point is that the two tools have different price tags.
To take a step further - most people debug using debuggers. I will not start a holy war on the merits of gdb of vc but a tool must exist.
In a live production situation you often don't have a debugger. The best you can do is printf() or log what's going on. Hell, sometimes you don't even have shell access to the machine running the application.
What is the difference between the aforementioned tools and another tool that takes a protocol byte stream and renders it human readable?
My roommate and I eventually concluded that for mechanisms like rpc, where machines are the only participants in a dialogue, of what value is human readability?
Ease of implementation and ease of debugging for the programmer. That is the value of a human readable protocol. All other things being equal, a human readable protocol will be easier (read: $$$ cheaper) than a non-readable one.
When tying together databases, server, RPC etc etc in a business environment, the thing you are trying to connect to, or work with will never be properly documented and any documentation that does exist will be wrong. You will debug. You will read the protocol. This is law.
The phrase "computer literate user" really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain.
-- Alan Cooper, "The Inmates are Running the Asylum", 1999
That is why it is a good idea to watch what users are doing and what their goals are.
What users think they need, and what they really need are often not the same thing. Users are users, not usability experts.
'Options' are good case in point. Often people want extra options to un-break some poorly chosen UI behaviour or functionality. It is beter to find out what is really causing the problem and fix that.
It's not all bad news. These things will contain computers. Imagine hacking your wheaties box to show something more interesting. You could directly recycle and reuse all of the 'paper' you receive.
If annoying animation gets out of hand, a few seconds in a microwave oven will probably fix the problem.;-)
You are assuming that when Prevayler restarts it reapplys the "half transaction" and corrupts the data. What is more likely to happen is that Prevayler applies the transaction log, sees that the last transaction is incomplete/corrupt, and then stops. Result: consistent DB state. (Actually the state just before the software failure.)
--
Simon
Re:Great for GC and dynamically typed languages
on
Athlon 64 Debuts
·
· Score: 1
You mean hack extra information into your pointers? I just read in the article that the pointers are 64 bits, but only 40 bits are used. Hey free bits!
You can argue that having 64bit registers and instructions means that you can tell the CPU to move 64bits in one go (instead of 2x 32bits). But with things like caching involved the impact on performance isn't likely to great. Also bear in mind that the serious number crunching is typically floating-point. Desktop CPUs have been pushing around floating-point numbers with more than 32bits for quite sometime now.
I remember the good old days when each new chip was 2-3 times faster than the last... I think thoses days are gone...
--
Simon
Re:are all the reviews by idiots?
on
Athlon 64 Debuts
·
· Score: 1
In fact the arguement for 64-bit processing is much more complicated. Simply put, 64-bit processing allows you to do two main things:
1. Move more data in one clock cycle
2. Perform more complicated instructions in one clock cycle
Actually 64 bit processing really isn't about that either. The primary benefit is a larger address space, mainly for use in database type applications. Your points 1 and 2 don't really have a lot to do with 64bit arch directly. Those problems are being attacked now by increasing address bus speed and width etc, pipelining, extra execution units etc. Unlike the transition in the past from 16bit (or 8bit) to 32bit architectures, the move to 64 won't affect most programs very much. Basically, 32bit integers are big enough for most applications to crunch with. During the 8bit and 16bit days everyone had to 'fake' 16 or 32 bit integer math on 8 or 16 bit CPUs by using multiple registers and instructions per math operation. This was of course much slower than just being able to do it direct on the CPU with out having to manage things like 'carry' bits and such.
Mind you, going to a 64bit instruction set also gives AMD an opportunity to extend the number of registers and implement other compatibility breaking cleanups.
The reason why this scrambling stuff works is that for the most part it maintains the graphic 'shape' of the words. We read words and phases not by looking at the letters but for recongnising the shape of the words. The first and last letters being important, but also the ascenders (liftbd) and the descenders (jpqyg), since the have the most impact of the shape of the word. This helps explain why uppercase is also hard and slow to read, even when spelt correctly -- all of the words have the same square shape. And it also explains why the scrambling trick does really work if you replace the middle letters with '-'s of underscores. It totally destroys the shape of the words.
Dumb question time. What psycho builds a pipe organ that goes so low that you can't even hear the notes? Once you can't hear the note wouldn't you stop making any low notes/keys?
How far below human hearing range are these infrasound notes anyway?
...and most so. There are truckloads of useful metadata out there that the computer could capture. For example:
* I get an email with a file from joe. I save the file to disk. My email program could associate the saved file with the email message and thread that now I could ask the computer for 'that file from joe', or 'that file from joe@citizen.org'. Keywords could also be taken from the email and associated with the file too.
* If I'm working on some files (say spreadsheets for example) and I cut and paste bits of info between the two files. The computer could easily infer some kind of relation or loose association between the two files.
* I grab a file from the web and save it. The computer could easily associate the file with where it came from and the page it is from. Hell, the computer could even check back at the web site and tell me if the original has been updated.
"What we're seeing is that those voluntary efforts are insufficient, and the repercussions are vast."
I think that here "voluntary efforts" refers to businesses' efforts to handle security without regulations and laws forcing them to (i.e. 'voluntarily'), and doesn't refer to Open Source developers.
Out with the old, in with the new.
Developers can adapt or fail. It doesnt seem wise to quit working towards better systems because some guy doesnt feel like replacing his widgets.
In case you didn't notice pal, breaking compatibility IS a big deal. It costs time and money. Most OSS projects don't run on money but they definately require time. Don't you think application developers have better things to do like implement wanted features instead of scrambling to fix previously working code? or having to deal with users using different incompatible versions of Qt/KDE, or dealing with making new RPMs,.debs etc, because compatibility is broken again. Don't YOU have better things to do than hunt down RPMs of software that have been compilied on just the right Qt/KDE versions as your own setup?
Can't we just enjoy a period of Things Just Working for a while?
Well, when you first touch vi, it's really cryptic, but if you read the first 4 pages of the tutorial, you can do basic text editing in less than 10 minutes.
When I pick up pretty much any decent GUI text editor I can do basic text editing in under 10 seconds, and without any tutorial whatsoever.
Not to mention that:
* I will already know where to look for the load/save commands, also what thier shortcuts will be.
* I can immediately see which functions/commands the editor has available (scan the menus).
* I can easily learn the keyboard shortcuts (they're on the menus) without needing any cheatsheet.
* I can generally work out complex functions just by looking at its interface (dialog box).
Good GUIs don't exist purely for the benifit of new users. They exist to make the interaction with the computer 'transparent' and take the mental load of experianced users who have more important things to think about. ('Transparent' here meaning that you can use the program without having to stop and think about its UI.)
C has 32 keywords and they grow in number at an incredibly slow rate. Yes, the problem of new keywords interfering with existing code is real but it is tiny
Um... so, it's not "absolutely no chance", but "tiny".
A couple of points:
* The chance really is tiny. Keywords are rarely added, and when they are they are chosen carefully.
* Code refactoring tools exist for the case when a clash occurs. Use them.
* Having manditory prefixes for all variables is a terrible price to pay in terms of readability (and not to mention typing). It's overkill on a massive scale.
* Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.
It's just a really bad trade-off allround, and like program line numbers, it's a concept that should be left to die.
Supporting gzip and bzip would probably be overkill. Besides I don't think that the main motivation for allowing zipped modules is compression and disk space. The real advantage is being able to distribute complete mulit-file modules as just one file, ala java's.jar files.
(Easier installation, less mess on the filesystem, etc)
I've been researching and working on making my machines quiet for the last month, but I've never heard of that.:-) Do you have any photos or links about using these things inside a PC?
Does anyone know how long the typical lifespan of such a heatsink is? Would it survive longer than a typical fan-based heatsink?
I run my boxes 24x7 and it seems that in a dusty environment - such as my appartment - all fans need to be replaced every year or so.
I think you just answered your own question.:-) In my experiance fans are _the_ most unreliable components in my systems. I'm using quality fans now and I've replace all fans on my GFX cards with heatsinks.
I imagine that a heat pipe would last much much longer than any fan. For a start they have almost no moving parts (well, no fiction really), and most of all no _exposed_ moving parts. (The pipe contains a liquid that moves/pumps heat by changing to a gas and back again.)
There are some good drives these days that are very quiet. Seagate Barracuda series drives are legendary among the Quiet PC crowd. Although other manufacturers are also bringing out quiet drives.
If you really want a silent computer you might as well get some information:
Slashdot Mirror
The difference between a readable and a non-readable protocol is that you can just log or snoop on the protocol stream directly with printf() etc and not have to write anything to decode it. Also your readable protocol is usually some form of text, so you can also immediately use any text handling tool at your disposal. Creating debugging routines costs extra time/money.
nevertheless a tool has been created.
You can look at it like that, but the point is that the two tools have different price tags.
To take a step further - most people debug using debuggers. I will not start a holy war on the merits of gdb of vc but a tool must exist.
In a live production situation you often don't have a debugger. The best you can do is printf() or log what's going on. Hell, sometimes you don't even have shell access to the machine running the application.
What is the difference between the aforementioned tools and another tool that takes a protocol byte stream and renders it human readable?
time/$$$/effort. Measure it however you like.
--
Simon
Ease of implementation and ease of debugging for the programmer. That is the value of a human readable protocol. All other things being equal, a human readable protocol will be easier (read: $$$ cheaper) than a non-readable one.
When tying together databases, server, RPC etc etc in a business environment, the thing you are trying to connect to, or work with will never be properly documented and any documentation that does exist will be wrong. You will debug. You will read the protocol. This is law.
--
Simon
--
Simon
--
Simon
'Options' are good case in point. Often people want extra options to un-break some poorly chosen UI behaviour or functionality. It is beter to find out what is really causing the problem and fix that.
--
Simon
If annoying animation gets out of hand, a few seconds in a microwave oven will probably fix the problem. ;-)
--
Simon
--
Simon
Actually on second thoughts, scrap that idea. It's a dumb idea.
Guess who wrote AmigaBASIC?
--
Simon
My point is that the width of the data bus isn't actually tied directly to the size of the integer registers.
Here is the first link off the Google: How motherboards works ;-)
You can argue that having 64bit registers and instructions means that you can tell the CPU to move 64bits in one go (instead of 2x 32bits). But with things like caching involved the impact on performance isn't likely to great. Also bear in mind that the serious number crunching is typically floating-point. Desktop CPUs have been pushing around floating-point numbers with more than 32bits for quite sometime now.
I remember the good old days when each new chip was 2-3 times faster than the last... I think thoses days are gone...
--
Simon
Mind you, going to a 64bit instruction set also gives AMD an opportunity to extend the number of registers and implement other compatibility breaking cleanups.
--
Simon
--
Simon
How far below human hearing range are these infrasound notes anyway?
--
Simon
* I get an email with a file from joe. I save the file to disk. My email program could associate the saved file with the email message and thread that now I could ask the computer for 'that file from joe', or 'that file from joe@citizen.org'. Keywords could also be taken from the email and associated with the file too.
* If I'm working on some files (say spreadsheets for example) and I cut and paste bits of info between the two files. The computer could easily infer some kind of relation or loose association between the two files.
* I grab a file from the web and save it. The computer could easily associate the file with where it came from and the page it is from. Hell, the computer could even check back at the web site and tell me if the original has been updated.
--
Simon
Here is the first link from Google on the subject:
http://www.noveltynet.org/content/paranormal/www.p arascope.com/articles/cnews/980325.htm
I very strongly recommend that everyone read "No Logo". Brands in education is a problem.
--
Simon
I think that here "voluntary efforts" refers to businesses' efforts to handle security without regulations and laws forcing them to (i.e. 'voluntarily'), and doesn't refer to Open Source developers.
Have a nice day.
--
Simon
Out with the old, in with the new.
Developers can adapt or fail. It doesnt seem wise to quit working towards better systems because some guy doesnt feel like replacing his widgets.
In case you didn't notice pal, breaking compatibility IS a big deal. It costs time and money. Most OSS projects don't run on money but they definately require time. Don't you think application developers have better things to do like implement wanted features instead of scrambling to fix previously working code? or having to deal with users using different incompatible versions of Qt/KDE, or dealing with making new RPMs, .debs etc, because compatibility is broken again. Don't YOU have better things to do than hunt down RPMs of software that have been compilied on just the right Qt/KDE versions as your own setup?
Can't we just enjoy a period of Things Just Working for a while?
--
Simon
More so:
Me: So where is that file?
GF: It's in Word.
Me: umm, but where is it on disk?
GF: It's in Word.
Me: oooook.
She is right more or less too. Open Word, File menu, look at the bottom. There it is. Disk? whatz'at?
--
Simon
--
Simon
--
Simon
When I pick up pretty much any decent GUI text editor I can do basic text editing in under 10 seconds, and without any tutorial whatsoever.
Not to mention that:
* I will already know where to look for the load/save commands, also what thier shortcuts will be.
* I can immediately see which functions/commands the editor has available (scan the menus).
* I can easily learn the keyboard shortcuts (they're on the menus) without needing any cheatsheet.
* I can generally work out complex functions just by looking at its interface (dialog box).
Good GUIs don't exist purely for the benifit of new users. They exist to make the interaction with the computer 'transparent' and take the mental load of experianced users who have more important things to think about. ('Transparent' here meaning that you can use the program without having to stop and think about its UI.)
--
Simon
Um... so, it's not "absolutely no chance", but "tiny".
A couple of points:
* The chance really is tiny. Keywords are rarely added, and when they are they are chosen carefully.
* Code refactoring tools exist for the case when a clash occurs. Use them.
* Having manditory prefixes for all variables is a terrible price to pay in terms of readability (and not to mention typing). It's overkill on a massive scale.
* Pulling data out of complex structures (think list of hash of foobar) is a nightmare in Perl thanks to these prefixes.
It's just a really bad trade-off allround, and like program line numbers, it's a concept that should be left to die.
--
Simon
--
Simon
--
Simon
I think you just answered your own question. :-) In my experiance fans are _the_ most unreliable components in my systems. I'm using quality fans now and I've replace all fans on my GFX cards with heatsinks.
I imagine that a heat pipe would last much much longer than any fan. For a start they have almost no moving parts (well, no fiction really), and most of all no _exposed_ moving parts. (The pipe contains a liquid that moves/pumps heat by changing to a gas and back again.)
--
Simon
There are some good drives these days that are very quiet. Seagate Barracuda series drives are legendary among the Quiet PC crowd. Although other manufacturers are also bringing out quiet drives.
If you really want a silent computer you might as well get some information:
How to Quiet the Thing
Silent PC Review
--
Simon