And while you're creating this community, your network is busily being infested with malware, unlicensed software and pirated music.
And how is this different from what happens when the company has a software monoculture designed and administered by its IT department and the major vendors (who design the major TARGETS of malware)?
So this is a whole hardware server module that you stuff into a switch? Why?
There are a bunch of things you'd like to do in a (non-backbone) router (i.e. and edge router or an enterprise router). Like high-intelligence packet filtering (such as malware detection). You'd like to do these in the routers at the edge of the ISP's network (where the packets for a customer finally come together after load-balancing multipathing), at the incoming firewall, and in the switches/routers within a campus LAN (i.e. to block the spread of viruses/worms once a behind-the-firewall machine is compromised.)
Some of the expertese to do this is in other companies than the router makers. It would cost a LOT to replicate this in a router company. (Example: The infrastructure to surveil for malware, analyze it, extract signatures, and maintain databases of them.) Better to partner with such companies, letting them provide the components they do well.
But there are a lot of potential problems with letting third parties build their software into the guts of the router:
- The processors and related infrastructure aren't optimized for performing this extra work.
- The amount of extra processing is enormous.
- Router internals don't provide a lot of protection from buggy - or malicious - code. Much of this is traded away for efficiency, minimizing the per-packet overhead. Major-league software QA substitutes for many hardware safeguards. Modules provided by third parties could break the router code, make it miss its performance requirements, and/or insert malware vulnerabilities in the routers themselves.
- Letting partners provide modules means giving them considerable visibility into the guts of the router. This means the router company's "secret sauce" recipies leave the building. The more partnering is done, the more potential leaks to the competition. (And the partners have much less incentive to protect the router company's secrets.)
A "resource card" design - a card fitting into a linecard slot, carrying the company's backplane routing interface plus commodity and/or special purpose processors, with their own API for plugging into the box's routing infrastructure, solves these problems.
- The box's routing code remains with the router company. It only needs to identify the packets requiring attention from the third-party resource, route them to the appropriate resource card, and route the result onward to the destination.
- The third party has an easy-to-understand environment that closely matches what they already work with and provides all the hooks they need. No "secret sauce" recipie required.
- The third party's code is compartmentalized - on hardware that provides security hooks as a given. Even if it is compromised the worst it can do is send malicious packets across the backplane to other line cards or across the control interface to the management processor(s) - and these can be alert for problems and protect themselves, just as they do from nasties arriving on network interfaces.
A switch (or router, whatever) chassis is a ridiculously valuable piece of real estate... why would you want to spend that slot space plugging in PCs when they could just as easily be somewhere else, on the end of an ethernet cable?
Because a backplane is SO much faster and a single box system SO much cheaper (especially in rack-unit rent) than a multi-box, router/server system.
For starters: A multi-box system doing any kind of filtering puts the packets through the switch TWICE, once on its way to the third-party resource, once on its way back. You'll need to chew up a slot or two just to provider enough networking bandwidth to exchange one slot's full line rate worth of traffic with the resource. So why fill the front of the card with interfaces and packet processors just for the handoff, when you could put the resource there in the first place and save a box?
There was a science fiction short story involving just such a reverse trackball - though larger than ten feet - being used to trap a victim. Once on the ball, feedback rotated the ball to bring him to the center and keep him there, no matter how he ran, jumped, or dodged.
Actually I'm pretty sure there's no way for this to convince someone it's real. You know that the ground is moving under you when you take a step so you'll always know you're not really going anywhere. Plus, people can sense acceleration.
Which is mostly done in the inner ear: Three "rate gyros" per ear (the semicircular canals) plus three linear accelleration sensors ditto (nerve cells with calcified masses on the ends).
But it turns out these can be fooled by elecrtostimulus from varying magnetic fields generated by coils mounted on a headpiece near them.
There has been at least one slashdot article on these - including adding them to a headpiece to mimic the head acceleration that would match a moving screen image to reduce "barfogenisis" and improve simulation game experience. Adding them to a 3-D VR simulation would be the next logical step.
With wall screens and projection onto the moving floor you could create the necessary visual illusion.
Some of this is no doubt spear-phishing. (Deploying newly-retuned spyware selectively against a target rather than globally, so it slips past signature-based malware detectors.) But I'd bet that most of this stuff is based on the malware developed for botnet-spamming and DDOSing, regular Phishing, etc.
We have a multibillion-dollar industry based on corrupting computers and stealing selected information from them, which the governments have virtually ignored while its techniques were honed. Now their own military secrets are the target of a similar attack. Any bets on whether it is built on the same code base.
Too late now, guys. The enemies' cyber-warfare departments now have the technology.
But I bet that, if you start finding and closing the barn doors even after most of the horses are gone, you'll find enough fingerprints and tire-tracks to trace down who did it. Hunt them down and take them out, and you'll eliminate a bunch of the talent that would otherwise be developing the technology further.
I'm a smart software developer, so I'm pretty sure my computer is not affected (secured hardware firewall, etc). But how can I be sure?
You can never be SURE. You can just be reasonably confident. Some particularly hard cases...
- Rootkits corrupt the very pieces of the OS and utilities that you'd use to detect them, to hide the presence of their components. (Also they can corrupt any antivirus tools they know about.)
- Virtualization allows things like "Blue Pill" to create a virtual environment where the malware is running in the virtualization server and nothing is visible in the virtual machine except maybe some odd delays.
- RAM-only infections can vanish completely at reboot - requiring a reinfection to researt and leaving no trace (unless they plant a restarter trojan somewhere on the system.)
Regarding rootkits: One thing you can do to detect them is to compare what the filesystem shows when the system is running to what it shows when a clean system is viewing it from a live CD. Tools based on this principle are available, to look for files that are "invisible" when the compromised system is running and for those that present different contents from what they should contain - or did contain at setup.
Then you're using an ISP that's working on the cheap - and will pay for it when edge routers crash and all the users connected through them suffer an outage.
(Exception might be, say, for a DSL carrier that has a DSLAM connected by multiple IP paths to the NOC and the BRAS/subscriber management function handled by a box at the NOC. Then the router(s) closest to the DSLAM can be flakey. But in that case they're not the "edge router". Instead the BRAS is the "edge router" and you have TWO single-points of failure that can take out a swath of users and thus should be telecom-quality: The BRAS and the DSLAM.)
For an example of a telecom-quality edge router look at the Redback Smartedge.
What we're looking at here is the Quality of Service question.
Different services require different service characteristics. For instance:
- File transfers can take "best effort" service. They don't care if the transit time of packets varies (jitter) or is long (large latency). They don't care if occasional packets get lost or corrupted because they can have them resent. They don't care if the rate is fast or slow - and can self-adjust to go as fast as possible to use the available bandwidth.
- Streaming protocols care about all of the above: If they're 2-way interactive they care about latency. They always care about jitter. They don't want packets to drop - but if occasional packets DO drop it's better for them to NOT try to get them resent, which would create massive jitter and latency. They have a bandwidth requirement that is either constant or related to what they are carrying - and has no relation to the actual speed available to the connection under varying amounts of congestion.
To serve both of these types of traffic on the same packet-switching network you have to treat them differently. Otherwise the file transfers will speed up to try to hog all the available bandwidth, dividing it evenly among themselves, and stomping on the streaming protocols. Things will only work for the streams on a best-effort net when all the file transfers are limited by some OTHER bottleneck and there is enough bandwidth ON EVERY HOP for essentially all the stream packets to go right through.
But because the streams have some other inherent bandwidth limit you CAN treat them differently. You can give them Quality of Service rules that puts them at the head of the line, limiting jitter, minimizing latency, and causing other types of packets to drop while they go through. And you can reserve bandwidth for them, refusing to set up the flow (connection) if there isn't enough to service them and have some left over for other services. Then you can guarantee they get delivered, while the file transfers etc. expand to hog and divide only the UNreserved bandwidth. Also: If they're going to multiple destinations you can use multicast and reserve bandwidth for only one copy while serving many endpoints.
And IPv4 was designed to do much of that: It has a "type of service" field that lets you declare what kind of service would be good for each packet. It didn't do bandwidth reservation (by itself). But you could declare preferences about latency, jitter, and drop probability.
Unfortunately, this means that packets could ask to be treated better than their competition. And it was completely on an honor system. And before streaming was widely deployed Microsoft deployed an IP stack that "improved" their product's performance by lying about the type of service the packets really needed, demanding stream-type service for everything, including file transfers. This got widely deployed. So ISPs generally don't honor the Type of Service bits, and QoS isn't widely deployed on the backbone.
Nowdays, in addition to the fast-as-mercury, dumb-as-rocks backbone routers, there are reliable-as-telecom, smart-as-firewalls edge routers, full of arrays of processors so they have a bunch of instruction executions available to think about every packet. These boxes can do things like act as a reverse-firewall to protect the network against cheaters, certifying that, if a given customer has bought - or temporarily reserved - a certain amount of high-QoS bandwidth he doesn't exceed it, and if necessary rewriting the QoS/Type of Service tagging so the backbone can trust the packets again.
So with the brains available to watch over the packets and apply rules, so that streams can get the bandwidth they need and file transfers can use all the rest on a common network, the question is what rules to apply.
Streams put a higher demand for service on the net - but have limited bandwidth. File transfers want bandwidth but are happy to take what's left after the strea
So it would be safe to say that if nothing can travel faster than the speed of light, we could witness objects distancing themselves at almost 3 times the speed of light, considering the addition of each:...
Nope. You can't observe objects whose effective speed in your reference frame - combining inflation with velocity - is greater than C. The light from them never reaches you and light from you can never reach them. From your point of view they're "off the edge". It's as if you and they were each below the event horizon of a black hole relative to each other.
(And sorry about an error in my previous post. The correct buzzword for the stretching of space is "inflation".)
Or at least that's how I understand it. IANAP(hysicist)
You are assuming that the scale of space is stable - that the separation of galaxies comes entirely from their material moving apart (at sublight speed) since they were essentially together in the moments after the big bang.
In fact space itself stretches. The separation of the material between pairs of distant (and near) galaxies comes from both their motion through space and the stretching (expansion) of the space between them.
The result is that sufficiently distant galaxies can be much farther apart than they could have traveled - even at the speed of light - through non-expanding space in the time since the big bang.
(I imagine many of you don't. But then the first machine I programmed for money used vacuum tubes for the DIODES.)
The same sorts of questions were being asked then. What could you possibly DO with a little home computer? They were SO underpowered compared with a mainframe.
The question was related to another one that had been asked before: "How many of these first IBM machines will we be able to sell?" "Well, 10 of them would do more arithmetic than all the accountants in the world..."
Surprise: When the price gets low enough there's a LOT of stuff you can do that you couldn't afford to do before.
So it's got a lot less processor and memory than the current top-of-the-line laptop? That puts it far ahead of the laptops - and desktops - of just a few years back. And it would run RINGS around the first Unix machine I bought for my personal use, back in the '70s. A couple megabyte or RAM? 80 Megs of hard drive? Floppies for backup? I still found PLENTY of stuff to do with it. Enough to justify the several thousands of dollars it cost - back when two hundred bux were worth about what a thousand is now.
Bring the price down to a hundred or two, for a small, light box with enough memory and processor to drive a decent display, audio, enough battery to keep it alive for a few hours, USB (or other) interface for external memory sticks / drives / cameras, and internal modem and wireless. Then you've got the bulk of what I need at a throwaway price.
I'd buy one for me, one for the wife, one for each nephew (if they don't have it already), put one in the vacation house to monitor the cameras and phone home in case of trouble, one for the townhouse to phone the vacation house when we're there ditto, one in the camping trailer, one on the boat, a spare in the trunk,... One breaks? Chuck it and get another.
As for the vendors: Fast nickels are better than slow dimes. Get the price point down far enough and you sell SO many of 'em that you more than make it up on volume.
Given the litigation risk, some open source companies, including Red Hat, acquire patents for the sole purpose of asserting them defensively in the event they are faced with a future lawsuit.
You could remove "open source" from the sentence above and it would be just as accurate.
Too true.
Since "going over to the hard side of the force" a few years ago - from software to hardware design - I've cranked out six patents for our company. (And we have a bunch of other people cranking, too.) We did it primarily as a defensive measure - and had to use it within a year, when a competitor (and major player in telecom) ran into financial trouble and became a patent troll to try to keep afloat. Turns out we hadn't infringed their patents - but it was still easier to cross-license than litigate.
The first published lament about non-free software that I'm aware of is a letter to Communications of the ACM from Professor Bernie Galler of the University of Michigan (an ol' prof of mine).
In it he gently flamed a couple programmers who were charging more than card/tape reproduction costs for a copy of a subroutine they had written in the course of their employment. He continued by predicting software-as-proprietary-product marketplace and its chilling effect on software development as a worst-case "if this goes on" scenario.
Don't recall the issue. But it's the one that also has Dijkstra's "GOTO statement considered harmful" letter, which puts it in 1968 or so.
Methinks "VIA will work with the community" translates to "VIA would really like the community to do all the work,
If they just publish the specs and stand back, I'm fine with that.
If they also release some of their current code under a free license it's a nice bonus.... and will be good enough to host it on their website", perhaps?
It's pretty obvious people don't understand the phrase "disruptive technology".
Hey!
- If Microsoft's marketing department can redefine "Wizard" from "Human computer expert acknowledged as exceptionally skilled by his peers" to "only moderately brain-damaged menu-driven installation/configuration tool",
- why can't Xiotech's marketing department redefine "disruptive technology" from "quantum leap in price/performance ratio of a competing technology based on a massively different architecture that makes it out-compete and displace the previous market-dominating solution" to "incremental generational upgrade in the latest model of our product which we hope will convince you to replace the competitor's product with ours (and disrupt both his business plan and your IT operation)"?
Gunnies were using that line for decades before Heston became head of the NRA. He just did it well enough and publicly enough that the media finally noticed - and then credited him with originating it.
However it would be particularly poetic if he were to be buried holding that particular gun in his "cold, dead hands". (I can just imagine him guffawing at the idea.)
Slashdot Mirror
Let's see how well a cluster of these does on nuclear weapon or reactor design.
And while you're creating this community, your network is busily being infested with malware, unlicensed software and pirated music.
And how is this different from what happens when the company has a software monoculture designed and administered by its IT department and the major vendors (who design the major TARGETS of malware)?
So this is a whole hardware server module that you stuff into a switch? Why?
There are a bunch of things you'd like to do in a (non-backbone) router (i.e. and edge router or an enterprise router). Like high-intelligence packet filtering (such as malware detection). You'd like to do these in the routers at the edge of the ISP's network (where the packets for a customer finally come together after load-balancing multipathing), at the incoming firewall, and in the switches/routers within a campus LAN (i.e. to block the spread of viruses/worms once a behind-the-firewall machine is compromised.)
Some of the expertese to do this is in other companies than the router makers. It would cost a LOT to replicate this in a router company. (Example: The infrastructure to surveil for malware, analyze it, extract signatures, and maintain databases of them.) Better to partner with such companies, letting them provide the components they do well.
But there are a lot of potential problems with letting third parties build their software into the guts of the router:
- The processors and related infrastructure aren't optimized for performing this extra work.
- The amount of extra processing is enormous.
- Router internals don't provide a lot of protection from buggy - or malicious - code. Much of this is traded away for efficiency, minimizing the per-packet overhead. Major-league software QA substitutes for many hardware safeguards. Modules provided by third parties could break the router code, make it miss its performance requirements, and/or insert malware vulnerabilities in the routers themselves.
- Letting partners provide modules means giving them considerable visibility into the guts of the router. This means the router company's "secret sauce" recipies leave the building. The more partnering is done, the more potential leaks to the competition. (And the partners have much less incentive to protect the router company's secrets.)
A "resource card" design - a card fitting into a linecard slot, carrying the company's backplane routing interface plus commodity and/or special purpose processors, with their own API for plugging into the box's routing infrastructure, solves these problems.
- The box's routing code remains with the router company. It only needs to identify the packets requiring attention from the third-party resource, route them to the appropriate resource card, and route the result onward to the destination.
- The third party has an easy-to-understand environment that closely matches what they already work with and provides all the hooks they need. No "secret sauce" recipie required.
- The third party's code is compartmentalized - on hardware that provides security hooks as a given. Even if it is compromised the worst it can do is send malicious packets across the backplane to other line cards or across the control interface to the management processor(s) - and these can be alert for problems and protect themselves, just as they do from nasties arriving on network interfaces.
A switch (or router, whatever) chassis is a ridiculously valuable piece of real estate... why would you want to spend that slot space plugging in PCs when they could just as easily be somewhere else, on the end of an ethernet cable?
Because a backplane is SO much faster and a single box system SO much cheaper (especially in rack-unit rent) than a multi-box, router/server system.
For starters: A multi-box system doing any kind of filtering puts the packets through the switch TWICE, once on its way to the third-party resource, once on its way back. You'll need to chew up a slot or two just to provider enough networking bandwidth to exchange one slot's full line rate worth of traffic with the resource. So why fill the front of the card with interfaces and packet processors just for the handoff, when you could put the resource there in the first place and save a box?
Putting the resource in a
For $80, you get a pretty full-featured Linux system.
According to the Wikipedia entery you quote, its status is "Discontinued - no longer shipping."
Is this correct? Is there a followon to replace it?
There was a science fiction short story involving just such a reverse trackball - though larger than ten feet - being used to trap a victim. Once on the ball, feedback rotated the ball to bring him to the center and keep him there, no matter how he ran, jumped, or dodged.
Actually I'm pretty sure there's no way for this to convince someone it's real. You know that the ground is moving under you when you take a step so you'll always know you're not really going anywhere. Plus, people can sense acceleration.
... gettin' there ...
Which is mostly done in the inner ear: Three "rate gyros" per ear (the semicircular canals) plus three linear accelleration sensors ditto (nerve cells with calcified masses on the ends).
But it turns out these can be fooled by elecrtostimulus from varying magnetic fields generated by coils mounted on a headpiece near them.
There has been at least one slashdot article on these - including adding them to a headpiece to mimic the head acceleration that would match a moving screen image to reduce "barfogenisis" and improve simulation game experience. Adding them to a 3-D VR simulation would be the next logical step.
With wall screens and projection onto the moving floor you could create the necessary visual illusion.
Gettin' there
Not to mention that "Silent Spring" was shown to be a crock.
Some of this is no doubt spear-phishing. (Deploying newly-retuned spyware selectively against a target rather than globally, so it slips past signature-based malware detectors.) But I'd bet that most of this stuff is based on the malware developed for botnet-spamming and DDOSing, regular Phishing, etc.
We have a multibillion-dollar industry based on corrupting computers and stealing selected information from them, which the governments have virtually ignored while its techniques were honed. Now their own military secrets are the target of a similar attack. Any bets on whether it is built on the same code base.
Too late now, guys. The enemies' cyber-warfare departments now have the technology.
But I bet that, if you start finding and closing the barn doors even after most of the horses are gone, you'll find enough fingerprints and tire-tracks to trace down who did it. Hunt them down and take them out, and you'll eliminate a bunch of the talent that would otherwise be developing the technology further.
I'm a smart software developer, so I'm pretty sure my computer is not affected (secured hardware firewall, etc). But how can I be sure?
You can never be SURE. You can just be reasonably confident. Some particularly hard cases...
- Rootkits corrupt the very pieces of the OS and utilities that you'd use to detect them, to hide the presence of their components. (Also they can corrupt any antivirus tools they know about.)
- Virtualization allows things like "Blue Pill" to create a virtual environment where the malware is running in the virtualization server and nothing is visible in the virtual machine except maybe some odd delays.
- RAM-only infections can vanish completely at reboot - requiring a reinfection to researt and leaving no trace (unless they plant a restarter trojan somewhere on the system.)
Regarding rootkits: One thing you can do to detect them is to compare what the filesystem shows when the system is running to what it shows when a clean system is viewing it from a live CD. Tools based on this principle are available, to look for files that are "invisible" when the compromised system is running and for those that present different contents from what they should contain - or did contain at setup.
Then you're using an ISP that's working on the cheap - and will pay for it when edge routers crash and all the users connected through them suffer an outage.
(Exception might be, say, for a DSL carrier that has a DSLAM connected by multiple IP paths to the NOC and the BRAS/subscriber management function handled by a box at the NOC. Then the router(s) closest to the DSLAM can be flakey. But in that case they're not the "edge router". Instead the BRAS is the "edge router" and you have TWO single-points of failure that can take out a swath of users and thus should be telecom-quality: The BRAS and the DSLAM.)
For an example of a telecom-quality edge router look at the Redback Smartedge.
What we're looking at here is the Quality of Service question.
Different services require different service characteristics. For instance:
- File transfers can take "best effort" service. They don't care if the transit time of packets varies (jitter) or is long (large latency). They don't care if occasional packets get lost or corrupted because they can have them resent. They don't care if the rate is fast or slow - and can self-adjust to go as fast as possible to use the available bandwidth.
- Streaming protocols care about all of the above: If they're 2-way interactive they care about latency. They always care about jitter. They don't want packets to drop - but if occasional packets DO drop it's better for them to NOT try to get them resent, which would create massive jitter and latency. They have a bandwidth requirement that is either constant or related to what they are carrying - and has no relation to the actual speed available to the connection under varying amounts of congestion.
To serve both of these types of traffic on the same packet-switching network you have to treat them differently. Otherwise the file transfers will speed up to try to hog all the available bandwidth, dividing it evenly among themselves, and stomping on the streaming protocols. Things will only work for the streams on a best-effort net when all the file transfers are limited by some OTHER bottleneck and there is enough bandwidth ON EVERY HOP for essentially all the stream packets to go right through.
But because the streams have some other inherent bandwidth limit you CAN treat them differently. You can give them Quality of Service rules that puts them at the head of the line, limiting jitter, minimizing latency, and causing other types of packets to drop while they go through. And you can reserve bandwidth for them, refusing to set up the flow (connection) if there isn't enough to service them and have some left over for other services. Then you can guarantee they get delivered, while the file transfers etc. expand to hog and divide only the UNreserved bandwidth. Also: If they're going to multiple destinations you can use multicast and reserve bandwidth for only one copy while serving many endpoints.
And IPv4 was designed to do much of that: It has a "type of service" field that lets you declare what kind of service would be good for each packet. It didn't do bandwidth reservation (by itself). But you could declare preferences about latency, jitter, and drop probability.
Unfortunately, this means that packets could ask to be treated better than their competition. And it was completely on an honor system. And before streaming was widely deployed Microsoft deployed an IP stack that "improved" their product's performance by lying about the type of service the packets really needed, demanding stream-type service for everything, including file transfers. This got widely deployed. So ISPs generally don't honor the Type of Service bits, and QoS isn't widely deployed on the backbone.
Nowdays, in addition to the fast-as-mercury, dumb-as-rocks backbone routers, there are reliable-as-telecom, smart-as-firewalls edge routers, full of arrays of processors so they have a bunch of instruction executions available to think about every packet. These boxes can do things like act as a reverse-firewall to protect the network against cheaters, certifying that, if a given customer has bought - or temporarily reserved - a certain amount of high-QoS bandwidth he doesn't exceed it, and if necessary rewriting the QoS/Type of Service tagging so the backbone can trust the packets again.
So with the brains available to watch over the packets and apply rules, so that streams can get the bandwidth they need and file transfers can use all the rest on a common network, the question is what rules to apply.
Streams put a higher demand for service on the net - but have limited bandwidth. File transfers want bandwidth but are happy to take what's left after the strea
So it would be safe to say that if nothing can travel faster than the speed of light, we could witness objects distancing themselves at almost 3 times the speed of light, considering the addition of each: ...
Nope. You can't observe objects whose effective speed in your reference frame - combining inflation with velocity - is greater than C. The light from them never reaches you and light from you can never reach them. From your point of view they're "off the edge". It's as if you and they were each below the event horizon of a black hole relative to each other.
(And sorry about an error in my previous post. The correct buzzword for the stretching of space is "inflation".)
Or at least that's how I understand it. IANAP(hysicist)
You are assuming that the scale of space is stable - that the separation of galaxies comes entirely from their material moving apart (at sublight speed) since they were essentially together in the moments after the big bang.
In fact space itself stretches. The separation of the material between pairs of distant (and near) galaxies comes from both their motion through space and the stretching (expansion) of the space between them.
The result is that sufficiently distant galaxies can be much farther apart than they could have traveled - even at the speed of light - through non-expanding space in the time since the big bang.
Unexpected, as in they told us very loudly that they were going to do it?
Yep!
They've told us a LOT of nice stuff they're "going to do" that they turned around and either didn't do or poisoned.
Embrace, extend, extinguish.
I'll believe it when/if it's finally done. (And even then I'll wonder what "gotchas" are included.)
(I imagine many of you don't. But then the first machine I programmed for money used vacuum tubes for the DIODES.)
... One breaks? Chuck it and get another.
The same sorts of questions were being asked then. What could you possibly DO with a little home computer? They were SO underpowered compared with a mainframe.
The question was related to another one that had been asked before: "How many of these first IBM machines will we be able to sell?" "Well, 10 of them would do more arithmetic than all the accountants in the world..."
Surprise: When the price gets low enough there's a LOT of stuff you can do that you couldn't afford to do before.
So it's got a lot less processor and memory than the current top-of-the-line laptop? That puts it far ahead of the laptops - and desktops - of just a few years back. And it would run RINGS around the first Unix machine I bought for my personal use, back in the '70s. A couple megabyte or RAM? 80 Megs of hard drive? Floppies for backup? I still found PLENTY of stuff to do with it. Enough to justify the several thousands of dollars it cost - back when two hundred bux were worth about what a thousand is now.
Bring the price down to a hundred or two, for a small, light box with enough memory and processor to drive a decent display, audio, enough battery to keep it alive for a few hours, USB (or other) interface for external memory sticks / drives / cameras, and internal modem and wireless. Then you've got the bulk of what I need at a throwaway price.
I'd buy one for me, one for the wife, one for each nephew (if they don't have it already), put one in the vacation house to monitor the cameras and phone home in case of trouble, one for the townhouse to phone the vacation house when we're there ditto, one in the camping trailer, one on the boat, a spare in the trunk,
As for the vendors: Fast nickels are better than slow dimes. Get the price point down far enough and you sell SO many of 'em that you more than make it up on volume.
Given the litigation risk, some open source companies, including Red Hat, acquire patents for the sole purpose of asserting them defensively in the event they are faced with a future lawsuit.
You could remove "open source" from the sentence above and it would be just as accurate.
Too true.
Since "going over to the hard side of the force" a few years ago - from software to hardware design - I've cranked out six patents for our company. (And we have a bunch of other people cranking, too.) We did it primarily as a defensive measure - and had to use it within a year, when a competitor (and major player in telecom) ran into financial trouble and became a patent troll to try to keep afloat. Turns out we hadn't infringed their patents - but it was still easier to cross-license than litigate.
They have not uploaded their full brief yet online, but promise to post it soon.
TFA now has a link to a PDF of the brief.
The first published lament about non-free software that I'm aware of is a letter to Communications of the ACM from Professor Bernie Galler of the University of Michigan (an ol' prof of mine).
In it he gently flamed a couple programmers who were charging more than card/tape reproduction costs for a copy of a subroutine they had written in the course of their employment. He continued by predicting software-as-proprietary-product marketplace and its chilling effect on software development as a worst-case "if this goes on" scenario.
Don't recall the issue. But it's the one that also has Dijkstra's "GOTO statement considered harmful" letter, which puts it in 1968 or so.
Methinks "VIA will work with the community" translates to "VIA would really like the community to do all the work,
... and will be good enough to host it on their website", perhaps?
If they just publish the specs and stand back, I'm fine with that.
If they also release some of their current code under a free license it's a nice bonus.
ANOTHER bonus!
I'll still need an antenna.
Really?
What are you currently using for an antenna? What's wrong with that?
So it's a werebrick.
A "man-brick"?
Yes! (For sufficiently smartphone-like values of "man".)
Time to consult the shade of Alan Turing...
"Bricked" is permanent. ... This, on the other hand, will be fixed by tomorrow.
So it's a werebrick.
It's pretty obvious people don't understand the phrase "disruptive technology".
Hey!
- If Microsoft's marketing department can redefine "Wizard" from "Human computer expert acknowledged as exceptionally skilled by his peers" to "only moderately brain-damaged menu-driven installation/configuration tool",
- why can't Xiotech's marketing department redefine "disruptive technology" from "quantum leap in price/performance ratio of a competing technology based on a massively different architecture that makes it out-compete and displace the previous market-dominating solution" to "incremental generational upgrade in the latest model of our product which we hope will convince you to replace the competitor's product with ours (and disrupt both his business plan and your IT operation)"?
Too bad the marketers who wrote it don't know how to speak English. Otherwise, we'd be able to understand and be excited about this.
They speak great management buzzword. But not tech - buzzword or otherwise.
Gunnies were using that line for decades before Heston became head of the NRA. He just did it well enough and publicly enough that the media finally noticed - and then credited him with originating it.
However it would be particularly poetic if he were to be buried holding that particular gun in his "cold, dead hands". (I can just imagine him guffawing at the idea.)