I was always under the impression that clean amplification had to do with a clean, stable power source, not high voltage.
At lower voltages, you have to draw more current for a given power output. More current equals more droop equals dirtier power.
Finally, how does 42V DC convert much easier to 120V AC? Don't you still have to use an inverter?
The chopper transistors handle 1/3rd the current, which means power losses are 1/9th as much. Keeping those transistors from burning themselves up is one of the major challenges in inverter design, so 1/9th the heat is a major win. Because there's less current, the input filter capacitors can be cheaper and crappier. The fact that the input voltage droops less means you can get away with even crappier input capacitors. Take it from a EE: switched converters get easier the closer the input and output voltages are.
This Usenet post claims lhd.zdnet.com went away because the server was cracked. Apparently ZDNet lacks some combination of backups, money, and willpower to bring it back.
It's official, Netcraft confirms lhd.zdnet.com is dead. It is certainly missed. Truly an Internet icon.;-)
Indeed. On average it takes 2**64 trials to find an MD5 collision by brute force. Furthermore, most of the files in a distro are packages that have internal cryptographic signatures. An attacker has to come up with a modification that simultaneously evades two separate checksums *and* forms a valid program. Absent major cryptoanalytic breakthroughs, it's not gonna happen.
The vendor's developers do not use well-secured machines on a well-secured network. Nor do they exhaustively review every single patch in every single source package. That's the weakest link in the security chain. All a PGP signature means is that the exploit was burned onto a CD and carried into a vault to be signed. Trusting the MD5 checksums available via HTTPS isn't appreciably less secure.
up2date is written in Python, and doing the stuff with python-base apparently hosed the interpreter and standard Python libraries. First remove the broken stuff with rpm -e python-base. If rpm complains, find the option to forcibly uninstall it. Then mount the install CD and do an rpm -i/mnt/cdrom/RedHat/RPMS/python-x.y.z/mnt/cdrom/RedHat/RPMS/python-devel-x.y.z. Again, force rpm to install if it complains. (Replace x.y.z with the appropriate version numbers.)
I'm working from memory (all I have here at work is a Windows machine) so double-check the man pages and package names in case I got anything wrong. Good luck!
I think that many people have been brainwashed into believing that comments are an acceptable way of making up for unreadable code.
While it is true that indiscriminant comments do not necessarily improve a codebase, the qmail source has **ZERO** useful comments [1]. Literally zero. Worse, variables are randomly named. My first impression on looking at it was "Why was an open source release run through a shrouded-source processor?"
A maintenance programmer confronted with this codebase is screwed. The semantics and types of data structures are a complete mystery. The maintainer has to either (1) guess blindly, or (2) reverse engineer the codebase. Ditto for auditors/reviewers. And that is a recipe for insecurity.
[1] IIRC there are only two comments at all, both of which are utterly useless.
Re:A warning to experimenters
on
Build Your Own ECG
·
· Score: 4, Informative
One of the reasons EKG systems (and I've used a fair handful) are expensive is that they go to extreme measures to insure that under no conditions will excessive current flow through the electrodes.
Indeed. I took apart a pulse oximeter that used two levels of transformer isolation, and it didn't even make a direct electrical connection to the patient. (They use optical sensors that clip onto your finger.)
I cannot comment on the original posting's circuit because it is slashdotted but I'm racking my brains trying to figure out how less than $10 can create a safe circuit... and it might be possible, maybe, but probably not.
It wasn't safe. Not no way, not no how. But I think you could do a pretty safe one for not a lot of money.
Use Ethernet transformers for isolation. They're rated for a coupla kV. The FDA probably wouldn't certify them, but I wouldn't be very afraid of them.
For power, use a 555 timer to drive one of the transformers. On the other side, rectify the current with a diode, filter it with a big cap.
To get the signal across the gap, use another 555 to turn the EKG voltage into frequency, and send the frequency across using the transformer. Feed it into the line input of the computer, do FM demodulation in software. Alternatively you can use a frequency-to-voltage converter (74HC-whatever PLL). Sound cards are terrible near DC, though, so doing the FM thing would give you the best signal.
Total cost would easily be less than $10. Even with medical-grade everything, you could probably make a production version for under $30 (in large quantities).
The implication is that if a dumb bot can get through your "agreement", you haven't attempted to withhold the resource until the client agrees to the contract, and thus there is no agreement.
It's trivial to use HTTP POST, a hidden form field, and cookies together to keep dumb bots out. You don't even have to make the user type anything in--that's just to provide additional evidence of intent to agree.
If you're in a situation where you need actual concrete legal advice, SLASHDOT IS NOT THE PLACE TO GO.
And how many lawyers know the legal implications of soliciting anonymous HTTP GET requests? How many know the semantic differences between GET and POST requests, and their relationship to the computer fraud and abuse statutes?
Furthermore, most law in this area is being made right now by the people actually working in this field. I.e., a large proportion of/. participants. The last thing we need is for the future to be built behind our backs by a bunch of expensive stuffed suits.
If you don't care, fine. Fuck off. Go build your own website dedicated to Fluffy Technology News That Doesn't Matter.
Aside from the well-known problems with any click-through agreement (contract between unknown parties, software circumvention, lack of notarization, etc.),...
You are talking out of your ass. An enforceable contract has four elements:
A meeting of the minds between the parties to the contract. Evidence of meeting of the minds can be provided by incorporating a unique element in the contract and requiring the web surfer to key it back in before they are allowed to proceed.
An exchange of "consideration", which basically means anything of value. If you look at several of the protected pages, that fact is evidence that you have received value. If the terms of the contract provide a competitive advantage to the web provider, that is evidence that they have received value.
A written statement of the terms. (Optional. If not present, damages are typically limited to something like $500 by the statute of frauds.)
Predication of consideration on agreement. I.e., they have to withhold the valuable consideration until after you have agreed to the terms. (Which means most "terms of service" pages are unenforceable bullshit. Advertising that you accept HTTP GET requests on port 80 is a solicitation, delivery of the requested page is consideration.)
If you don't want to have to look at a click-through page before reading your competitor's deep dark secrets, just download what you want from a public web cache.
How can Googlebot waltz right in if there's a click-through barrier?
But there is not a technical means of determining intent over the current version of HTTP.
Yes, there is. HTTP POST requests are defined as causing the server to take some action (and not merely provide data back). Ergo, using a POST against the will of the server operator is generally a violation of the computer abuse statutes.
Until then, honoring click-through pages in the breach will only harm the internet.
Bullshit. First, I can find anybody's competitors in a couple of seconds. If I find their proposed agreement too annoying (or their Javascript, or their blink tags...), I go someplace else. The invisible hand will guide them toward an appropriate level of onerousness. Second, randomly smashing contracts because somebody thinks they are unfair would be bad. What's the difference between John "Dumbass" Lawyer's click-through page, the agreement for real-time NASDAQ quotes, and a 1-Click purchase order? Nothing! It would wreck Internet commerce to capriciously void contracts because some jackoff decides they're unfair.
...it's just the boom of a couple steam-pipes busting from too much pressure.
More like a big industrial boiler exploding, a rather spectacular event. If it uses water and graphite/metal, they burn and make an even bigger explosion. God help you if it's a metallic uranium/liquid sodium reactor.
And that's assuming the reactivity doesn't get much worse than, say, the Chernobyl disaster. There's no telling how high you can make it go without a lot of modelling that nobody has done.
Besides, who says you have to blow up the reactor. It'd be a lot of fun to slowly crank up the neutrino beam to increase the reactor power level, then turn it off suddenly and surprise the living hell out of the reactor operators.
And even if you could build it, how do you aim it? You can't exactly gimbal a 1000 km ring.
And how do you lock onto the targets? If you can get a conventional radiation detector close enough, you might as well just send in the Marines to pick up the nuke. You can't use neutrinos to detect them because (1) detector efficiency is abysmal and (2) fission reactors and the sun provide a tremendous background signal.
And suppose you do somehow build an aimable neutrino beam. What happens if a rogue operator points it at a fission reactor? You're right that it almost certainly cannot ignite the pit of a bomb because the storage configuration has a low reactivity. Reactors, on the other hand, operate near unity reactivity. I don't know enough about reactor physics to say what is possible, but I'd be very worried that the neutrino beam could liberate enough unexpected heat to put the reactor in a positive temperature coefficient of reactivity regime. Boom. Like the Chernobyl disaster, but potentially much bigger.
As everyone knows, SDI cannot stop terrorists from flying planes into buildings, using suitcase nuclear weapons, launching missiles from off-shore platforms, etc, etc.
But lots of nations don't destroy for the hell of it, they do things for a purpose. Consider a nation like the Democratic People's Republic of Korea. They don't want nukes so they can carry out an attack. Actually attacking would put them at the sharp end of a very pointy stick. Not even the Glorious Leader is that stupid. What they need is to create an unmistakable threat of an attack, in order to extract concessions.
A suitcase nuke or an offshore platform doesn't create a sustainable threat. If you advertise a suitcase nuke, it gets taken away. If you don't advertise it, you don't get concessions. If you actually use it, not only don't you get concessions, but the Marines get sent in back home. Ditto for an offshore platform.
What you have to do is create a credible, sustainable threat, which means nuclear ballistic missiles in your own territory. That raises the bar high enough that the US will (probably) leave you alone as long as you don't actually launch.
But consider what happens if the US and allies have a missile shield with an 83% failure rate. 83% is terrible, right? Wrong. It means the enemy has to play Russian roulette to make that threat. If they win, the peasants get a little more food or heating oil. If they lose, the Marines spread them out on a cracker and eat them as a snack. Even a crappy missile defense system makes a huge difference in the strategic balance.
It also makes a big difference in an all out nuclear exchange between major powers. 83% losses is vastly better than 100% losses.
Nuclear power, the magnetron, guidance systems, nitinol (nickel titanium Naval Ordnance Laboratory; a.k.a. memory metal), antidotes for acetylcholinesterase inhibitors, vaccines for a variety of horrible diseases, protocols that revolutionized emergency medicine in the '70s, demining research and development, vast improvements in cryptography, spread spectrum radio, countless advances in metallurgy, etc.
What good does classified research do for us?
Nothingk, comrade! Is plot by capitalist pig-dogs to take means of production away from... uh... I get back to you.
Perhaps it's time to upgrade your pre-1.0 Moz build?
I'm running 1.0.1.
I'm looking at it on a 1280x1024 screen, in Mozilla 1.3, and I see none of the problems you describe...
Crank your resolution up to 1600x1200 and set the font to a comfortable size: the site disintegrates into unusability. Leave the original fonts alone and the characters are 8 pixels tall--small enough to draw 120 lines of text on the screen--which is hideously painfully small.
ESPN.com is simply an amateurish disaster, designed by people who know little about standards, browsers, or usability.
Indeed. I'm looking at ESPN.com on a 1600x1200 screen under a recent Mozilla, and it is an unreadable, shitty looking pile of dreck:
Text hanging across columns
Inter-line spacing too small so the characters of one line physically overlap the previous line
Ugly line breaks in the scores sidebar
Content boxes that stick down too far and chop of the top of the box below
Boxes that have their bottom part chopped off by the box below (they screwed it up both ways)
Shitty Javascript menus with expander buttons tiled when they should be singlets
Their "lite" site has hideous colors
And none of this is Mozilla's fault. When Part 1 of the interview came out last week, I looked at the side from Internet Explorer while I was at work. It looked more reasonable, as long as you used a magnifying glass: they hardcode all sizes in terms of pixels, and I have a decent monitor/video card. Morons, you're bus is leaving...
Another thing: the whole site is branded as "ESPN.com", but they forcibly redirect to espn.go.com. Forget the technical idiocy: these folks can't even manage a coherent branding strategy.
People make fun of the work I do using HTML 4.01, but they render nicely on most browsers, render usably on nearly all browsers, and validate so I have confidence that there aren't any lurking bugs.
Before you try and sue someone, check your time cards! If you didn't indicate on the time card that you worked overtime (and signed it), then you have lied... good luck getting any money!
Indeed. If your salary was contributed to by any gov't contracts, prepare for the auditors. (I recommend a heavy water-based lubricant, such as KY Jelly.)
The IRS might also be interested for all those hours the company received as income "under the table".
The kluges mentioned by you and others only work for the address bar of web browsers, and they differ incompatibly between browsers.
Saying Linux is bad because it isn't like Windows doesn't hold up. You're just not used to the way it does things.
Like fucking hell I'm not. I've spent thousands of hours each using both X and Microsoft Windows, and one of the things I do for a living is design user interfaces.
The X clipboard is constantly surprising. When you want to copy something to another location, you can't just stick it in the clipboard, you have to plan out in advance the logistics of anything else you might wish to highlight. Needing to edit something else before pasting is very common, and the X clipboard makes that maximally difficult. Accidentally selecting text causes the clipboard to be destroyed, which is a real PITA when using a crappy touchpad. Closing a window also tends to destroy the contents of the clipboard.
In contrast, the Microsoft-style clipboard is rarely surprising. It's hard to put the wrong thing in the clipboard, and it always pastes exactly where and when you want.
in mozilla you can middle click directly into the page and it loads the new link
Unless your pointer is on a link, which causes an unwanted new window to open. Or on certain HTML widgets, which do nothing, Or on certain other HTML widgets, which cause an obnoxious "The URL is not valid and cannot be loaded" dialog that you have to manually clear. Or on text widgets, which paste the text into themselves. Oh, and Moz lets you have multiple highlighted pieces of text at the same time in the same frame. (But they're not exactly the same. Real highlighting is black. Faux highlighting turns gray.)
That's idiotic. Moz took a complex context-dependent UI and made it more complex and more context-dependent.
If you want a UI to be friendly and popular, it needs to be simple, easy to get correct results, and context-free.
I should have made it clear that I think most of the performance problems are implementation issues, not fundamental flaws in the X protocol.
As to Microsoft Windows being faster, I think that's mostly because of people and money issues. With Windows, one development team had access and control to everything: consultation with video card and motherboard engineers, total control of the OS kernel, control of the libraries, very strong influence on the drivers, and control of the flagship apps. They also had hundreds of millions of dollars in funding. I don't like the architecture of the resulting product, but there's no arguing that Microsoft throws money at performance bottlenecks until they go away.
X can't even blit a window around the screen at full speed.
I don't know whether X can move rectangles entirely server-side, but it doesn't matter. The X protocol could readily be extended to handle it. The much harder problem is to fix the window managers to exploit the feature. It simply takes an enormous amount of programming to make a fast, pretty graphical environment. And this isn't a matter of having too many layers: MS Windows has lots of layers too. The difference is that large, well-funded teams of programmers have optimized the piss out of Windows.
It is interesting to turn the question around: Microsoft has spent several orders of magnitude more resources developing the graphical parts of Windows than has been spent on XFree86. So why doesn't Windows generate several orders of magnitude more revenue per desktop for its customers? Even though XFree86 has been managed ineffectively the last few years, they've given terrific bang for the buck.
If uploading to remote servers was transparent, and handled by the windowing system itself, then it shouldn't be a problem.
A lot of X application writers don't have a good handle on server-side caching of images. The widget libraries need much better documentation about how to do things the "right way".
Given that so many popular widget sets / window managers / desktop themes do like to stick shading and bitmaps on everything... wouldn't it make sense to fix the X protocol so that such eye candy can be displayed without slowing the system down too much?
Sorry--I oversimplified. X is quite capable of doing that stuff very, very fast. The problem is careless application programmers who don't exploit X's ability to do server-side caching. If you have to retransfer 50 GUI widgets on every screen redraw, things get very slow.
Slashdot Mirror
Search SourceForge for "IRC".
It's official, Netcraft confirms lhd.zdnet.com is dead. It is certainly missed. Truly an Internet icon. ;-)
Indeed. On average it takes 2**64 trials to find an MD5 collision by brute force. Furthermore, most of the files in a distro are packages that have internal cryptographic signatures. An attacker has to come up with a modification that simultaneously evades two separate checksums *and* forms a valid program. Absent major cryptoanalytic breakthroughs, it's not gonna happen.
IMHO, YMMV, ...
I'm working from memory (all I have here at work is a Windows machine) so double-check the man pages and package names in case I got anything wrong. Good luck!
They just stick a little rubber plug in the duct at the corner of the eye. It's quick and easy, and trival to reverse.
A maintenance programmer confronted with this codebase is screwed . The semantics and types of data structures are a complete mystery. The maintainer has to either (1) guess blindly, or (2) reverse engineer the codebase. Ditto for auditors/reviewers. And that is a recipe for insecurity.
[1] IIRC there are only two comments at all, both of which are utterly useless.
Use Ethernet transformers for isolation. They're rated for a coupla kV. The FDA probably wouldn't certify them, but I wouldn't be very afraid of them.
For power, use a 555 timer to drive one of the transformers. On the other side, rectify the current with a diode, filter it with a big cap.
To get the signal across the gap, use another 555 to turn the EKG voltage into frequency, and send the frequency across using the transformer. Feed it into the line input of the computer, do FM demodulation in software. Alternatively you can use a frequency-to-voltage converter (74HC-whatever PLL). Sound cards are terrible near DC, though, so doing the FM thing would give you the best signal.
Total cost would easily be less than $10. Even with medical-grade everything, you could probably make a production version for under $30 (in large quantities).
It's trivial to use HTTP POST, a hidden form field, and cookies together to keep dumb bots out. You don't even have to make the user type anything in--that's just to provide additional evidence of intent to agree.
Furthermore, most law in this area is being made right now by the people actually working in this field. I.e., a large proportion of /. participants. The last thing we need is for the future to be built behind our backs by a bunch of expensive stuffed suits.
If you don't care, fine. Fuck off. Go build your own website dedicated to Fluffy Technology News That Doesn't Matter.
And that's assuming the reactivity doesn't get much worse than, say, the Chernobyl disaster. There's no telling how high you can make it go without a lot of modelling that nobody has done.
Besides, who says you have to blow up the reactor. It'd be a lot of fun to slowly crank up the neutrino beam to increase the reactor power level, then turn it off suddenly and surprise the living hell out of the reactor operators.
And how do you lock onto the targets? If you can get a conventional radiation detector close enough, you might as well just send in the Marines to pick up the nuke. You can't use neutrinos to detect them because (1) detector efficiency is abysmal and (2) fission reactors and the sun provide a tremendous background signal.
And suppose you do somehow build an aimable neutrino beam. What happens if a rogue operator points it at a fission reactor? You're right that it almost certainly cannot ignite the pit of a bomb because the storage configuration has a low reactivity. Reactors, on the other hand, operate near unity reactivity. I don't know enough about reactor physics to say what is possible, but I'd be very worried that the neutrino beam could liberate enough unexpected heat to put the reactor in a positive temperature coefficient of reactivity regime. Boom. Like the Chernobyl disaster, but potentially much bigger.
A suitcase nuke or an offshore platform doesn't create a sustainable threat. If you advertise a suitcase nuke, it gets taken away. If you don't advertise it, you don't get concessions. If you actually use it, not only don't you get concessions, but the Marines get sent in back home. Ditto for an offshore platform.
What you have to do is create a credible, sustainable threat, which means nuclear ballistic missiles in your own territory. That raises the bar high enough that the US will (probably) leave you alone as long as you don't actually launch.
But consider what happens if the US and allies have a missile shield with an 83% failure rate. 83% is terrible, right? Wrong. It means the enemy has to play Russian roulette to make that threat. If they win, the peasants get a little more food or heating oil. If they lose, the Marines spread them out on a cracker and eat them as a snack. Even a crappy missile defense system makes a huge difference in the strategic balance.
It also makes a big difference in an all out nuclear exchange between major powers. 83% losses is vastly better than 100% losses.
The DPI setting on XFree86 is erratic anyway, but that's beside the point.
ESPN.com is simply an amateurish disaster, designed by people who know little about standards, browsers, or usability.
And none of this is Mozilla's fault. When Part 1 of the interview came out last week, I looked at the side from Internet Explorer while I was at work. It looked more reasonable, as long as you used a magnifying glass: they hardcode all sizes in terms of pixels, and I have a decent monitor/video card. Morons, you're bus is leaving...
Another thing: the whole site is branded as "ESPN.com", but they forcibly redirect to espn.go.com. Forget the technical idiocy: these folks can't even manage a coherent branding strategy.
People make fun of the work I do using HTML 4.01, but they render nicely on most browsers, render usably on nearly all browsers, and validate so I have confidence that there aren't any lurking bugs.
The IRS might also be interested for all those hours the company received as income "under the table".
The X clipboard is constantly surprising. When you want to copy something to another location, you can't just stick it in the clipboard, you have to plan out in advance the logistics of anything else you might wish to highlight. Needing to edit something else before pasting is very common, and the X clipboard makes that maximally difficult. Accidentally selecting text causes the clipboard to be destroyed, which is a real PITA when using a crappy touchpad. Closing a window also tends to destroy the contents of the clipboard.
In contrast, the Microsoft-style clipboard is rarely surprising. It's hard to put the wrong thing in the clipboard, and it always pastes exactly where and when you want.
Unless your pointer is on a link, which causes an unwanted new window to open. Or on certain HTML widgets, which do nothing, Or on certain other HTML widgets, which cause an obnoxious "The URL is not valid and cannot be loaded" dialog that you have to manually clear. Or on text widgets, which paste the text into themselves. Oh, and Moz lets you have multiple highlighted pieces of text at the same time in the same frame. (But they're not exactly the same. Real highlighting is black. Faux highlighting turns gray.)That's idiotic. Moz took a complex context-dependent UI and made it more complex and more context-dependent.
If you want a UI to be friendly and popular, it needs to be simple, easy to get correct results, and context-free.
As to Microsoft Windows being faster, I think that's mostly because of people and money issues. With Windows, one development team had access and control to everything: consultation with video card and motherboard engineers, total control of the OS kernel, control of the libraries, very strong influence on the drivers, and control of the flagship apps. They also had hundreds of millions of dollars in funding. I don't like the architecture of the resulting product, but there's no arguing that Microsoft throws money at performance bottlenecks until they go away.
I don't know whether X can move rectangles entirely server-side, but it doesn't matter. The X protocol could readily be extended to handle it. The much harder problem is to fix the window managers to exploit the feature. It simply takes an enormous amount of programming to make a fast, pretty graphical environment. And this isn't a matter of having too many layers: MS Windows has lots of layers too. The difference is that large, well-funded teams of programmers have optimized the piss out of Windows.It is interesting to turn the question around: Microsoft has spent several orders of magnitude more resources developing the graphical parts of Windows than has been spent on XFree86. So why doesn't Windows generate several orders of magnitude more revenue per desktop for its customers? Even though XFree86 has been managed ineffectively the last few years, they've given terrific bang for the buck.
A lot of X application writers don't have a good handle on server-side caching of images. The widget libraries need much better documentation about how to do things the "right way".