Yes, broadband pricing and deployments are squishy. There's a lot of FUD in the statistics. But consider this:
- Macromedia and other code is way over fat - Most HTML editors also produce fat code - Most codecs produce lousy compression and very lossy, too - Dynamic HTML is fatter still, including the page you're reading - CSS simply adds to the problem by oversending code/data - XML is another bucket of overkill; every page sends a new schema, and a bunch of unneeded, duplicate info - Poor local/user cache mgmt causes too many page reloads - RSS/Atom feeds send tons of duplicate new hits, and is a waste of good bandwidth - This is all seven bit stuff, every single line of it, yet we use no basic compression on the Internet to send pages, because somehow, that would be evil. I say, use source compression with understandable decoders that have security built into them on the client, then compress the hell out of the entire Internet! - Same thing goes for email-- compress it! If LEV and other compression techniques are so efficient, USE THEM! But no, then we couldn't easily have our favorite pcap file filters find credit cards. The mind reels.
The cure has always been, fatter pipes. How about more efficient pipes? The broadband we use to day are like the 1960 Pontiacs-- muscle cars designed to burn rubber, when all we wanted to do was to get from here to there quickly and nicely and safely. What happened to that mentality-- efficiency? Everyone got sold on the idea of the fat pipe, and now we all have to have them, rather than tightening code and codecs. Fie.
This isn't about publicity, this is about competition and fair use of trademarks. They could do much better on commercials rather than lawyers. And until trademark law is changed, using them in your context without permission is a violation of trademark law. That's the crux of the case.
If you believe any publicity is good, then why did McDonald's clean up their act....why did Microsoft actually pay (if pitiable) attention to security? I suppose you code in VB, too...
If the LKP were compiled in with the UnixWare kernel, then a big problem exists. But it's a discrete piece of code, and where it lives doesn't make much difference. I'll concede that architecturally, it lives as a module, but a driver lives in the same space, too. A driver can either be called (discrete execution) or compiled in with the kernel. When it's compiled in with the kernel, it's GPL by origin.
You'll note they never charged for the LKP; no media charge or any other charge. The kernel is a static piece of code inherently. The kernel is modded by modules, loadable drivers, but is a discrete functional unit. If/when a module or driver or other code is loaded that talks to the kernel, it's no different than other parts of the kernel that function doing various things and no different than an object module that reads USB ports.
If the code is stolen and not GPL'd, and unacknowledged/relicensed then there are both license and copyright problems.
If the blanket GPL license covers this (I can't cite case law either way) then its use, subject to the terms, is legal for SCO to distribute having followed the tenets of the license.
But I maintain that these are discrete instances, no matter where they live. If a call is intercepted, and translated and sent to the UnixWare kernel for processing, this action is no different than an Intel Pro100 driver catching a call and sending it to a Broadcom interface. Both, in my mind, are legal. If the driver is GPL, and compiled into UnixWare specifically, then it's a violation of the GPL and likely copyright, too.
This 'adaptation layer' is probably the only way to, in a legally licensed way, get Linux components to work satisfactorily given the differences in how compiled apps want to see kernel behaviour, and the reverse. Were it source in the kernel then compiled, no-- poisoned. But it's not. Your definition of linkage is imprecise for what's intended by the GPL, in my estimation.
Let's take a look here at the models for a moment:
- Let's take OOo as an example. The app loads into X or a variant, creates its own name and data space, looks for sysinternals, and marches on for the user. Completely safe sex code. No bad things were passed; but the kernel passed data to and fro through various devices and so on in its quest to complete its interaction with OOo apps.
- Now, we're asking the UnixWare kernel to run an application that wants Linux calls supported. The app, at runtime, sees the loaded module variables co-resident (but doesn't know that) and functionals along merrily; the UnixWare kernel merrily sends info back and forth along the way. The LKP intercepts various calls, and passes them up to the 'host' kernel.
In both cases, the kernels were autonomous. SCO, provided they support the GPL characteristics of the Linux code it uses and otherwise complies with copyright notices, hasn't mixed a source with a source; two or more binaries are talking to each other. Yes, the module is linked in with the kernel. So are drivers, and other GPL code... like Apache, SAMBA, MySQL, and other GPL apps. These programs link with the kernel, too. They're not compiled in with the kernel, and the LKP isn't either.
I see a big distinction between a discrete module execution (autonomous and distinct as a NIC driver, and equally as loadable and dischargeable) and grafting Linux source code into their kernel or gcc library source, or even header files, etc into a singularity.;
The module adds functionality. It has no real 'end' product, but is discrete and therefore untainted/contaminated/poisoned.
It isn't cross-compiled. It's a run-time add-in. And SCO supplied the GPL.... but I haven't cracked that package in a year or more, and so the exact wording is a bit fuzzy. But it was the GNU GPL (and used 'empirically'== my words to cover all the FOSS stuff inside their box. Then they withdrew the LKP for reasons unstated, but surmised).
I have a copy of both UnixWare, its licenses, and the LKP. Although I haven't grepped it for symbols, I still maintain that the GPL allows this in the same way that Solaris can use GPL code. If the modules are compiled and discrete, then they're as functionally autonomous as driver code.
No, UnixWare isn't GPL's or even has an approved open license. Separately compiled code, e.g. a loadable module (this is what the LKP is) doesn't contaminate UnixWare's code. If they were compiled in together, that bag of worms is likely contaminated.
But they're not. It's a module; it's loaded to be used. As a servent of the resident kernel, its subsidiary to it, and doesn't use its source, just its functionality as though it were any other OSS.
So what happens when GPL-licensed code is loaded into a GPL-licensec kernel? Here's the poison test, and it's not poisoned. The whole UnixWare license came with the GPL, as well as a few other licenses, including the LGPL.
So is it poisoned? No. Is it a copyright violation? No Is it a GNU GPL violation? No. Sorry to burst your bubbles. I dislike SCO along with the rest, but in this case, they covered their posteriors. READ THE LICENSES THAT CAME WITH THE PRODUCT.
They lost out to DLink and Buffalo. Look at how WiFi went, like hotcakes, and it still does.
So now, all the vendor communities want to snack on our desire to better farther faster cheaper. Duck.
Do we need these standards? Egads- think of how truly awful that WEP and WPA are. With luck, there'll be better security, too.
Wait-- you say that they haven't thought of that ?*#@)@?????
No, we don't need more. We need to fix what we have first, and strangle the engineers that thought up, with the best intentions that the road to hell are paved with, WEP/WPA security.
You rationalize everything. In a civil society, we agree on rules because we need to. We follow them because to be uncivil, you become a detriment to those that have.
Yes, civil disobedience can be used to effectively protest conditions, but then, as a consequence, society (the civil) looks at whether it's cogent to adopt the protester's demands or needs or accomodations.
Theft is theft. It's not an absolute, and the philosophers needn't agree because they don't apply philosophy. But civil behavior warrants describing the tone and tenor of behavior between people and groups.
Philosophers, like Kant, Pascal, and many others have had a great influence on how that system of laws and desired interpersonal behavior contexts can and do work.
Theft is still theft. Your attempt to abstract it doesn't justify it it. Take responsibility for your actions, rather than make behavior a loosey-goosey sort of find a rationalism-to-fit sort of existence.
There are no absolutes, but that's a good thing; there are certainly tenets that bear examination, rather than rationalization.
you described co-discovery. These are different things. Theft is when you steal something you know about. Discovery is when you come upon something someone else knows. Trespass is being somewhere where you're physically/virtually unwanted. This isn't linguistic BS; these are readily defined semantical concepts within the context of your parable. Theft is not commendable. Co-discovery is. So is justice.
In your analogy, the information garnerer is a thief, and maybe a murderer. The 'clever Thief' is a co-discoverer and a hero because he shares the information.
You must separate what I own in information about myself, and what other information--not about myself-- that I own. If you find out that I've been married four times and use that against me, this is public information that can be found. If you find out that I haven't registered my dog, then you've broken into my home and examined private characteristics of me. These are two different things.
So, I don't buy your parable. Theft is theft. Co-discovery and the ability to go where others go is ok. The source of the water can be public knowledge. If the thief trespassed on the land to find the water, then there's a small crime involved. Whether the crime is overlooked because of the discovery is something else. That's why we have prosecutors, and warrants, and civil process.
"...reconcile the liberty of other people's information with the privacy of their own?"
We don't. Both are private and to be respected. We should own information about ourselves. If we release it, we do so cognitively. If you steal it, you're a thief. If-- and only if-- we allow its use, then it's ok, but only within that context, and that context alone.
This is a setup question. It's a flame magnet of biblical proportions. Jerk.
It's totally insecure (see the Defcon traps info). Bluesnarfing has become de riguer. I wish it wasn't so, but BT is designed with very poor/weak security in mind. And in my Mac, BT audio is disabled (the skunks!). It now suffers from multiple standards implementations, and has been far surpassed by 802.11.
I have a BT earpiece for my Ericsson mobile. I have a BT dongle for my Mac and PC; at least the PC works. And I'll tell you that most BT implementations are as insecure as the day is long.
And so the comparison is apt-- WiMax, WiFi and BT are all insanely and mind-numbingly insecure by poor and rotten design. I wish it weren't so.
Sure 75megabits/sec. Just like that good old payload for 802.11g/a. Optimumly, you get less than half of that raw. Now share it. Walk around a corner. Oh, maybe it's protected with WEP, too. Broadband noise sources nearby? All those frequencies won't hop? So sad.
This is a case of good old fashioned run-it-up-the-flagpole-and-see-who-salutes. As mentioned above, find me a Wimax card at Fry's. I dare you. Oh, sure, Intel wants to put Wimax into everything. Just like Nokia and Ericsson wanted Bluetooth in everything. Does this industry ever learn? Is the thought of killing telcos so passionate that people are blinded by the reality of the real limitations of 802.16 and it's ZERO deployment numbers? Anyone seen a VoIP 802.16 phone-- anywhere?
So, this is another one to toss in the round file, folks. None of it is real. Please tilt the mirrors away from the smoke.
Google: mike lynn blackhat cisco ios and have a good time.
If you understand both IOS and assembler pcode, you can catch his drift. These are chinks in the otherwise solid armor that Cisco has.
The exposure of this, along with other security bugs that organizations have, ranging from Microsoft down to Linus's best code, are important to know at the second of apparency. That's when both the good guys and the bad guys can get to work. I hope the bad guys lose, and they usually do. But prevention of exposure is just a ticking bomb. This kind of bomb kills most of the Internet as we know it. And maybe it'll give Cisco a wake up call that it better diffuse the bomb and improve their quality.
The slides speak for themselves. High five to Mike Lynn and all who are tenacious enough to bring security solidification to the core of the net. And a fie on those that would stop him, and all those that endeavor to bring quality to communications. And to all of those that went to Defcon, be proud to be a part of liberty. It smells of good dirt.
And all of your points have fallacies....
on
Basics of RAID
·
· Score: 1
If you buy junk, expect it to fail-- and that means anything sold by Dell to start with.
1) RAID controllers-- real ones-- are highly reliable. Yes, a power supply surge can kill anything. Yes, backups are a good idea. But if you're in production, backups are stupid; high-availability clustering is important. Client/users that need RAID get a benefit.
2) See the comment about using Dell products; they make nothing themselves, and therefore are the WalMart of computer quality-- driving OEM costs to the bone, and therefore, often quality, too.
3) There's no research or logic that supports this. It's another computer urban myth.
4) Once again, buying from the bottom of the barrel is an unwise posture for a serious professional. This isn't ToolTime.
Backups are a good idea, They work when data can actually be restored in under a century. It's nice also to have mirrored external USB 2.X or FireWire/IEEE1394 drives, too. But a majority of people don't even do that. In production environments, you're destined to do it and for all the right reasons. But it's not a good excuse to re-install an OS. You do that only with Windows. A real OS can live a long healthy life.
The two major reasons, based on the success of Apple's current models, are 1) DRM and 2) application emulation possibilities with a mature and cogent CPU road map.
TCG is unfortunately, a joke. But so is the rest of the oxymoron called system security. Today in the NYT, there was a column about people simply throwing their machines away when they became too crammed with malware. Enter now, the era of dispoable computing.
All GBE cards are FC on the MAC layer. Get over it.
Here's where the problems come in:
1) buses suck. PCI-X is fast; a faster bus clock is better still 2) the problems for GBE NICs are, in no special order: dropping crap packets; cleaning up dirty cache (a huge problem for clusters, where this product is poised); session/protocol relationship managment; buffering up misrouted UDP; managing evil ports (setting them up and tearing them down); managing proxies and work arounds (a little SIP anyone? Burping up your IPSec???) 3) making the driver aware of what's going on so sessions don't vomit 4) not bothering the freaking CPU chipset every few milliseconds with useless crap
So, if they do any of these things, bless them and send me the bill. Because (save TOE cards), all of them hassle the drivers and chipsets to no end with stuff that could easily be offloaded. And to those that say, just put more cheapo load-balanced hardware on the job-- you're a chump and deserve to have stuff blown to bits when you mulitply failure points with junko doorstop hardware boxes with all of the brains of a goose.
Actually, there is some evidence about EMI/RFI
on
Tinfoil Hat House
·
· Score: 1
Studies have shown that people in rural areas using mobile phones have a higher incidence of brain tumors. Additional incidences of higher frequency exposure have been shown to cause DNA changes, ostensibly by rattling your proteins apart.
Lupus, an autoimmune disorder, is similar to temporal arteritis and other disease where the body actually starts inflaming and perhaps attacking itself through misidentification of conditions. Some feel that this might happen because of exposure to microwave leakage (ovens, and other 2.2-2.4Ghz items such as cordless phones, remote speakers, and 802..11b/g products) that cause localized inflamations that the body perceives as antigen reaction, then sends lymph and other things to do battle with non-existent, unidentified bad things. These 'soldiering' effects then, having not much to do, disrupt local tissues.
No, there's not a lot of data out there. But we are indeed bombarded by all sort of stuff, and waiting for the producers of products to research (expensively) the reactions will be like waiting for Godot, or worse, the government
A few years back, it was demonstrated to me that military radar could selectively fry a single goose in a formation from over five miles away. The poor things would burst into flames. Lower frequency RF, like living under a broadcast tower, doesn't seem to have as much problem as higher frequencies, including those that resonate water in microwave ovens. With so much spectra being used, few studies have been done stepping a few Hertz at a time, then looking to see what changes have occured, given various energy strengths, and localized conditions, like the presence of water and various minerals-- let alone DNA. Still further tests over a period of time given these variables, is entirely elusive-- there just isn't data.
I wouldn't therefore dismiss claims out of hand, despite the fact that they sound superficially quite silly. Schizophrenia? Perhaps, but don't dismiss this entirely. Liberty requires accomodating goofy, yet harmless people.
The list of PC/x86 Flops would fill pages
on
Apple's First Flops
·
· Score: 2, Insightful
Jobs, if anything, was focused and visionary. A few screwups are nothing compared to the IBM PC Jr, and assorted junk that arrived from loads of other vendors. If nothing, he's consistent and found religion when he jumped to NeXt. The Darwin kernel and other human-factor profiles, along with sheer beauty make Job's stuff like Sony's product lines used to be.
The list of other flops is miles long. Flops are good: they test engineers and the market place. Some items are ahead of their time, others behind, and still others are just really bad ideas.
Ten years ago, 1995, the transports were boot sector viruses, and occasionally executables masquerading as something else.
Today, malware comes in many forms, ranging from RPC attacks/port probes, through to the most common exploit-- email. Add on top of that, browser infections, executables loaded by duping the user (and so on). Fewer than 1 in 10 had email in 1995, and the Internet was barely alive with a pulse. Today, we have multiple transports-- and perhaps five times the users and a far higher international penetration of PCs.
The same can be said for mobiles. And now they're a group that seems to be on the list for buggering.
Ten years ago, viruses on PCs were uncommon. Now it's all we can do to keep a machine from being rooted in minutes. While the infrastructure of mobile companies is well NAT'd, the possibilities of people inadvertently getting snarfed is really high. There are five OS makers out there for mobiles, none of which do anything at all to warn users about possible hijacks, phishing schemes (how about emulating that Coke machine that someone wants to buy from?), viruses, and/or data theft (Hi Paris!) and other threats.
Where Symantec is invested in making us paranoid, why not act now, rather than patch phones until we're blue in the face, like we do with PCs? I really disliked Symantec's other seemingly bogus announcements about threats where they don't exist, but with mobile use approaching a billion users, it's just bound to happen and with widespread panic.
Imagine not wanting to use your mobile because you're worried about what might happen. Imagine getting popups, or very unexpected use from a hijack. Or having your authentication swiped then charged up the yang in the next few minutes. Sound like fun? It will happen. Or: just ignore it. It'll go away. Those bad people won't hurt you on your mobile.
It's a nice historical piece on GUIs. It lacks lots of the drivers for things: vector graphics and math co-processors; how CPU and bus design influences graphics; multi-tasking/multi-threading and its impact on GUI design; the advent of the (awful) browser; the Unix schisms and X developments; other window managers and their designs; how the awfulness of small, low-res monitors impacted GUI design; memory mapping, bit mapping vs drawing real lines in the kinescope fashion.
Also glossed: Desqview, RHM, and other neo-GUIs. MIA: sub-PC GUIs in monochrome (Palm and Newton) and other non-traditional form factors. But overall-- good article. I guess he needs a book to do it all justice.
You can do a lot with cash. The best thing to do is not to burn it, rather to build on it. Basic capitalism. Sun, like other tech corps, get too much of it. Then when their stock goes down, they're worth more as a purchased entity-- but a buyout ploy will make their stock buoy, which drives away the buyers. You could buy SGI for the Friday price and instantly earn several hundred million after you burned everything and fired everyone. This is bad economics. The current climate discourages boldness, and makes people think inside the box. The box is the big problem. Sun is trying to become IBM, whose dependency on hardware is nearly over. They're a services company, and a pretty good one. They used to be iron movers, and left the details to others. These days, iron rusts, but the needs that they serviced remain the same. Sun is starting to learn that lesson, but their run rate is too high to sustain both models successfully. They need to sack a bunch of nitwits at the top and get back to their entreprenurial roots before they just wither in a pile of bile.
Slashdot Mirror
Yes, broadband pricing and deployments are squishy. There's a lot of FUD in the statistics. But consider this:
- Macromedia and other code is way over fat
- Most HTML editors also produce fat code
- Most codecs produce lousy compression and very lossy, too
- Dynamic HTML is fatter still, including the page you're reading
- CSS simply adds to the problem by oversending code/data
- XML is another bucket of overkill; every page sends a new schema, and a bunch of unneeded, duplicate info
- Poor local/user cache mgmt causes too many page reloads
- RSS/Atom feeds send tons of duplicate new hits, and is a waste of good bandwidth
- This is all seven bit stuff, every single line of it, yet we use no basic compression on the Internet to send pages, because somehow, that would be evil. I say, use source compression with understandable decoders that have security built into them on the client, then compress the hell out of the entire Internet!
- Same thing goes for email-- compress it! If LEV and other compression techniques are so efficient, USE THEM! But no, then we couldn't easily have our favorite pcap file filters find credit cards. The mind reels.
The cure has always been, fatter pipes. How about more efficient pipes? The broadband we use to day are like the 1960 Pontiacs-- muscle cars designed to burn rubber, when all we wanted to do was to get from here to there quickly and nicely and safely. What happened to that mentality-- efficiency? Everyone got sold on the idea of the fat pipe, and now we all have to have them, rather than tightening code and codecs. Fie.
This isn't about publicity, this is about competition and fair use of trademarks. They could do much better on commercials rather than lawyers. And until trademark law is changed, using them in your context without permission is a violation of trademark law. That's the crux of the case.
If you believe any publicity is good, then why did McDonald's clean up their act....why did Microsoft actually pay (if pitiable) attention to security? I suppose you code in VB, too...
If the LKP were compiled in with the UnixWare kernel, then a big problem exists. But it's a discrete piece of code, and where it lives doesn't make much difference. I'll concede that architecturally, it lives as a module, but a driver lives in the same space, too. A driver can either be called (discrete execution) or compiled in with the kernel. When it's compiled in with the kernel, it's GPL by origin.
You'll note they never charged for the LKP; no media charge or any other charge. The kernel is a static piece of code inherently. The kernel is modded by modules, loadable drivers, but is a discrete functional unit. If/when a module or driver or other code is loaded that talks to the kernel, it's no different than other parts of the kernel that function doing various things and no different than an object module that reads USB ports.
If the code is stolen and not GPL'd, and unacknowledged/relicensed then there are both license and copyright problems.
If the blanket GPL license covers this (I can't cite case law either way) then its use, subject to the terms, is legal for SCO to distribute having followed the tenets of the license.
But I maintain that these are discrete instances, no matter where they live. If a call is intercepted, and translated and sent to the UnixWare kernel for processing, this action is no different than an Intel Pro100 driver catching a call and sending it to a Broadcom interface. Both, in my mind, are legal. If the driver is GPL, and compiled into UnixWare specifically, then it's a violation of the GPL and likely copyright, too.
This 'adaptation layer' is probably the only way to, in a legally licensed way, get Linux components to work satisfactorily given the differences in how compiled apps want to see kernel behaviour, and the reverse. Were it source in the kernel then compiled, no-- poisoned. But it's not. Your definition of linkage is imprecise for what's intended by the GPL, in my estimation.
Let's take a look here at the models for a moment:
- Let's take OOo as an example. The app loads into X or a variant, creates its own name and data space, looks for sysinternals, and marches on for the user. Completely safe sex code. No bad things were passed; but the kernel passed data to and fro through various devices and so on in its quest to complete its interaction with OOo apps.
- Now, we're asking the UnixWare kernel to run an application that wants Linux calls supported. The app, at runtime, sees the loaded module variables co-resident (but doesn't know that) and functionals along merrily; the UnixWare kernel merrily sends info back and forth along the way. The LKP intercepts various calls, and passes them up to the 'host' kernel.
In both cases, the kernels were autonomous. SCO, provided they support the GPL characteristics of the Linux code it uses and otherwise complies with copyright notices, hasn't mixed a source with a source; two or more binaries are talking to each other. Yes, the module is linked in with the kernel. So are drivers, and other GPL code... like Apache, SAMBA, MySQL, and other GPL apps. These programs link with the kernel, too. They're not compiled in with the kernel, and the LKP isn't either.
I see a big distinction between a discrete module execution (autonomous and distinct as a NIC driver, and equally as loadable and dischargeable) and grafting Linux source code into their kernel or gcc library source, or even header files, etc into a singularity.;
The module adds functionality. It has no real 'end' product, but is discrete and therefore untainted/contaminated/poisoned.
It isn't cross-compiled. It's a run-time add-in. And SCO supplied the GPL.... but I haven't cracked that package in a year or more, and so the exact wording is a bit fuzzy. But it was the GNU GPL (and used 'empirically'== my words to cover all the FOSS stuff inside their box. Then they withdrew the LKP for reasons unstated, but surmised).
I have a copy of both UnixWare, its licenses, and the LKP. Although I haven't grepped it for symbols, I still maintain that the GPL allows this in the same way that Solaris can use GPL code. If the modules are compiled and discrete, then they're as functionally autonomous as driver code.
No, UnixWare isn't GPL's or even has an approved open license. Separately compiled code, e.g. a loadable module (this is what the LKP is) doesn't contaminate UnixWare's code. If they were compiled in together, that bag of worms is likely contaminated.
But they're not. It's a module; it's loaded to be used. As a servent of the resident kernel, its subsidiary to it, and doesn't use its source, just its functionality as though it were any other OSS.
So what happens when GPL-licensed code is loaded into a GPL-licensec kernel? Here's the poison test, and it's not poisoned. The whole UnixWare license came with the GPL, as well as a few other licenses, including the LGPL.
So is it poisoned? No.
Is it a copyright violation? No
Is it a GNU GPL violation? No.
Sorry to burst your bubbles. I dislike SCO along with the rest, but in this case, they covered their posteriors. READ THE LICENSES THAT CAME WITH THE PRODUCT.
They lost out to DLink and Buffalo. Look at how WiFi went, like hotcakes, and it still does.
So now, all the vendor communities want to snack on our desire to better farther faster cheaper. Duck.
Do we need these standards? Egads- think of how truly awful that WEP and WPA are. With luck, there'll be better security, too.
Wait-- you say that they haven't thought of that ?*#@)@?????
No, we don't need more. We need to fix what we have first, and strangle the engineers that thought up, with the best intentions that the road to hell are paved with, WEP/WPA security.
You rationalize everything. In a civil society, we agree on rules because we need to. We follow them because to be uncivil, you become a detriment to those that have.
Yes, civil disobedience can be used to effectively protest conditions, but then, as a consequence, society (the civil) looks at whether it's cogent to adopt the protester's demands or needs or accomodations.
Theft is theft. It's not an absolute, and the philosophers needn't agree because they don't apply philosophy. But civil behavior warrants describing the tone and tenor of behavior between people and groups.
Philosophers, like Kant, Pascal, and many others have had a great influence on how that system of laws and desired interpersonal behavior contexts can and do work.
Theft is still theft. Your attempt to abstract it doesn't justify it it. Take responsibility for your actions, rather than make behavior a loosey-goosey sort of find a rationalism-to-fit sort of existence.
There are no absolutes, but that's a good thing; there are certainly tenets that bear examination, rather than rationalization.
you described co-discovery. These are different things. Theft is when you steal something you know about. Discovery is when you come upon something someone else knows. Trespass is being somewhere where you're physically/virtually unwanted. This isn't linguistic BS; these are readily defined semantical concepts within the context of your parable. Theft is not commendable. Co-discovery is. So is justice.
In your analogy, the information garnerer is a thief, and maybe a murderer. The 'clever Thief' is a co-discoverer and a hero because he shares the information.
You must separate what I own in information about myself, and what other information--not about myself-- that I own. If you find out that I've been married four times and use that against me, this is public information that can be found. If you find out that I haven't registered my dog, then you've broken into my home and examined private characteristics of me. These are two different things.
So, I don't buy your parable. Theft is theft. Co-discovery and the ability to go where others go is ok. The source of the water can be public knowledge. If the thief trespassed on the land to find the water, then there's a small crime involved. Whether the crime is overlooked because of the discovery is something else. That's why we have prosecutors, and warrants, and civil process.
"...reconcile the liberty of other people's information with the privacy of their own?" We don't. Both are private and to be respected. We should own information about ourselves. If we release it, we do so cognitively. If you steal it, you're a thief. If-- and only if-- we allow its use, then it's ok, but only within that context, and that context alone. This is a setup question. It's a flame magnet of biblical proportions. Jerk.
I double dog dare you to do wardriving for a WiMax tower. There aren't any. A lot of good that'll do Vonage.
It's totally insecure (see the Defcon traps info). Bluesnarfing has become de riguer. I wish it wasn't so, but BT is designed with very poor/weak security in mind. And in my Mac, BT audio is disabled (the skunks!). It now suffers from multiple standards implementations, and has been far surpassed by 802.11.
I have a BT earpiece for my Ericsson mobile. I have a BT dongle for my Mac and PC; at least the PC works. And I'll tell you that most BT implementations are as insecure as the day is long.
And so the comparison is apt-- WiMax, WiFi and BT are all insanely and mind-numbingly insecure by poor and rotten design. I wish it weren't so.
Sure 75megabits/sec. Just like that good old payload for 802.11g/a. Optimumly, you get less than half of that raw. Now share it. Walk around a corner. Oh, maybe it's protected with WEP, too. Broadband noise sources nearby? All those frequencies won't hop? So sad.
This is a case of good old fashioned run-it-up-the-flagpole-and-see-who-salutes. As mentioned above, find me a Wimax card at Fry's. I dare you. Oh, sure, Intel wants to put Wimax into everything. Just like Nokia and Ericsson wanted Bluetooth in everything. Does this industry ever learn? Is the thought of killing telcos so passionate that people are blinded by the reality of the real limitations of 802.16 and it's ZERO deployment numbers? Anyone seen a VoIP 802.16 phone-- anywhere?
So, this is another one to toss in the round file, folks. None of it is real. Please tilt the mirrors away from the smoke.
Google: mike lynn blackhat cisco ios and have a good time.
If you understand both IOS and assembler pcode, you can catch his drift. These are chinks in the otherwise solid armor that Cisco has.
The exposure of this, along with other security bugs that organizations have, ranging from Microsoft down to Linus's best code, are important to know at the second of apparency. That's when both the good guys and the bad guys can get to work. I hope the bad guys lose, and they usually do. But prevention of exposure is just a ticking bomb. This kind of bomb kills most of the Internet as we know it. And maybe it'll give Cisco a wake up call that it better diffuse the bomb and improve their quality.
The slides speak for themselves. High five to Mike Lynn and all who are tenacious enough to bring security solidification to the core of the net. And a fie on those that would stop him, and all those that endeavor to bring quality to communications. And to all of those that went to Defcon, be proud to be a part of liberty. It smells of good dirt.
If you buy junk, expect it to fail-- and that means anything sold by Dell to start with.
1) RAID controllers-- real ones-- are highly reliable. Yes, a power supply surge can kill anything. Yes, backups are a good idea. But if you're in production, backups are stupid; high-availability clustering is important. Client/users that need RAID get a benefit.
2) See the comment about using Dell products; they make nothing themselves, and therefore are the WalMart of computer quality-- driving OEM costs to the bone, and therefore, often quality, too.
3) There's no research or logic that supports this. It's another computer urban myth.
4) Once again, buying from the bottom of the barrel is an unwise posture for a serious professional. This isn't ToolTime.
Backups are a good idea, They work when data can actually be restored in under a century. It's nice also to have mirrored external USB 2.X or FireWire/IEEE1394 drives, too. But a majority of people don't even do that. In production environments, you're destined to do it and for all the right reasons. But it's not a good excuse to re-install an OS. You do that only with Windows. A real OS can live a long healthy life.
They have a broader set of ordinances mandating fibre to the home, and business-- all with nearby access to the National Lamba Rail.
The good news is: this is a trend that ought to shake up how we think of broadband-- as a utility like water, gas, and electricity.
The two major reasons, based on the success of Apple's current models, are 1) DRM and 2) application emulation possibilities with a mature and cogent CPU road map.
TCG is unfortunately, a joke. But so is the rest of the oxymoron called system security. Today in the NYT, there was a column about people simply throwing their machines away when they became too crammed with malware. Enter now, the era of dispoable computing.
All GBE cards are FC on the MAC layer. Get over it.
Here's where the problems come in:
1) buses suck. PCI-X is fast; a faster bus clock is better still
2) the problems for GBE NICs are, in no special order: dropping crap packets; cleaning up dirty cache (a huge problem for clusters, where this product is poised); session/protocol relationship managment; buffering up misrouted UDP; managing evil ports (setting them up and tearing them down); managing proxies and work arounds (a little SIP anyone? Burping up your IPSec???)
3) making the driver aware of what's going on so sessions don't vomit
4) not bothering the freaking CPU chipset every few milliseconds with useless crap
So, if they do any of these things, bless them and send me the bill. Because (save TOE cards), all of them hassle the drivers and chipsets to no end with stuff that could easily be offloaded. And to those that say, just put more cheapo load-balanced hardware on the job-- you're a chump and deserve to have stuff blown to bits when you mulitply failure points with junko doorstop hardware boxes with all of the brains of a goose.
Studies have shown that people in rural areas using mobile phones have a higher incidence of brain tumors. Additional incidences of higher frequency exposure have been shown to cause DNA changes, ostensibly by rattling your proteins apart.
Lupus, an autoimmune disorder, is similar to temporal arteritis and other disease where the body actually starts inflaming and perhaps attacking itself through misidentification of conditions. Some feel that this might happen because of exposure to microwave leakage (ovens, and other 2.2-2.4Ghz items such as cordless phones, remote speakers, and 802..11b/g products) that cause localized inflamations that the body perceives as antigen reaction, then sends lymph and other things to do battle with non-existent, unidentified bad things. These 'soldiering' effects then, having not much to do, disrupt local tissues.
No, there's not a lot of data out there. But we are indeed bombarded by all sort of stuff, and waiting for the producers of products to research (expensively) the reactions will be like waiting for Godot, or worse, the government
A few years back, it was demonstrated to me that military radar could selectively fry a single goose in a formation from over five miles away. The poor things would burst into flames. Lower frequency RF, like living under a broadcast tower, doesn't seem to have as much problem as higher frequencies, including those that resonate water in microwave ovens. With so much spectra being used, few studies have been done stepping a few Hertz at a time, then looking to see what changes have occured, given various energy strengths, and localized conditions, like the presence of water and various minerals-- let alone DNA. Still further tests over a period of time given these variables, is entirely elusive-- there just isn't data.
I wouldn't therefore dismiss claims out of hand, despite the fact that they sound superficially quite silly. Schizophrenia? Perhaps, but don't dismiss this entirely. Liberty requires accomodating goofy, yet harmless people.
Jobs, if anything, was focused and visionary. A few screwups are nothing compared to the IBM PC Jr, and assorted junk that arrived from loads of other vendors. If nothing, he's consistent and found religion when he jumped to NeXt. The Darwin kernel and other human-factor profiles, along with sheer beauty make Job's stuff like Sony's product lines used to be.
The list of other flops is miles long. Flops are good: they test engineers and the market place. Some items are ahead of their time, others behind, and still others are just really bad ideas.
Ten years ago, 1995, the transports were boot sector viruses, and occasionally executables masquerading as something else.
Today, malware comes in many forms, ranging from RPC attacks/port probes, through to the most common exploit-- email. Add on top of that, browser infections, executables loaded by duping the user (and so on). Fewer than 1 in 10 had email in 1995, and the Internet was barely alive with a pulse. Today, we have multiple transports-- and perhaps five times the users and a far higher international penetration of PCs.
The same can be said for mobiles. And now they're a group that seems to be on the list for buggering.
Ten years ago, viruses on PCs were uncommon. Now it's all we can do to keep a machine from being rooted in minutes. While the infrastructure of mobile companies is well NAT'd, the possibilities of people inadvertently getting snarfed is really high. There are five OS makers out there for mobiles, none of which do anything at all to warn users about possible hijacks, phishing schemes (how about emulating that Coke machine that someone wants to buy from?), viruses, and/or data theft (Hi Paris!) and other threats.
Where Symantec is invested in making us paranoid, why not act now, rather than patch phones until we're blue in the face, like we do with PCs? I really disliked Symantec's other seemingly bogus announcements about threats where they don't exist, but with mobile use approaching a billion users, it's just bound to happen and with widespread panic.
Imagine not wanting to use your mobile because you're worried about what might happen. Imagine getting popups, or very unexpected use from a hijack. Or having your authentication swiped then charged up the yang in the next few minutes. Sound like fun? It will happen. Or: just ignore it. It'll go away. Those bad people won't hurt you on your mobile.
It's a nice historical piece on GUIs. It lacks lots of the drivers for things: vector graphics and math co-processors; how CPU and bus design influences graphics; multi-tasking/multi-threading and its impact on GUI design; the advent of the (awful) browser; the Unix schisms and X developments; other window managers and their designs; how the awfulness of small, low-res monitors impacted GUI design; memory mapping, bit mapping vs drawing real lines in the kinescope fashion.
Also glossed: Desqview, RHM, and other neo-GUIs. MIA: sub-PC GUIs in monochrome (Palm and Newton) and other non-traditional form factors. But overall-- good article. I guess he needs a book to do it all justice.
You can do a lot with cash. The best thing to do is not to burn it, rather to build on it. Basic capitalism. Sun, like other tech corps, get too much of it. Then when their stock goes down, they're worth more as a purchased entity-- but a buyout ploy will make their stock buoy, which drives away the buyers. You could buy SGI for the Friday price and instantly earn several hundred million after you burned everything and fired everyone. This is bad economics. The current climate discourages boldness, and makes people think inside the box. The box is the big problem. Sun is trying to become IBM, whose dependency on hardware is nearly over. They're a services company, and a pretty good one. They used to be iron movers, and left the details to others. These days, iron rusts, but the needs that they serviced remain the same. Sun is starting to learn that lesson, but their run rate is too high to sustain both models successfully. They need to sack a bunch of nitwits at the top and get back to their entreprenurial roots before they just wither in a pile of bile.