It actually has effects felt outside the Internet.
Bands are now made and broken across Tom's goddamn friend list counts. Movies like Step It Up rake in totally unexpected profits due to MySpace promotion. Kids who would never get laid in HS 4 years ago are now gettin the hookup, dawg.
Its size dwarves LJ, Xanga, and the others.
Even I was coerced into getting a profile. ME! That says something. (Then again I only use it to spy on other people)
4, 6) They were first. 5) Blogging HAS changed things. Not that I like that, but I accept it. 10) Slashdot was the first to do that PLUS a threaded discussion system that was 1) anonymous if you wanted 2) immune from moderators who could edit/delete contents 12) Craigslist was the first new site (not born of a oldworld BBS) that became the defacto BBS for whole cities. This was before "local" websites were all the rage.
I remember that. Didn't it basically let you broadcast the presence of and search other member's NT shares? SMB/RPC in the open over the Internet. Man, those were the days.
I seriously doubt these tests will ever come to pass. DARPA doesn't like to run tests that other scientifically advanced nations can detect and then point a damning finger at. They'd be more likely to fund research for high MeV particle resistant satellite and aircraft systems (since that has no noticeable external effects... keep the "advantage" secret)
Multiplication is equivalent to a convolution of two discrete arrays. It's a O(N^2) operation if done using the multiply, shift, add method. An FFT (of which there are integer variations) is a O(N*log(N)) manipulation of the data. When you transform both arrays, you do a straight component multiply, then you untransform the result.
3 * O(N log N) + O(N) O(N ^ 2) for very large multiplicands.
We're talking about way outside of the range of most scientific or financial applications. It's an important speedup for mathematical research and certain kinds of statistical analysis.
They are useful for storing decimal quantites unambigously in databases and flat files. However they are not as useful for code that manipulates them heavily:
* MP libraries that use full-on binary representation are always faster and more memory efficient unless we're talking about an IBM mainframe * It's a pain to up and downconvert from "normal" datatypes
In-memory representations are probably better served by 64-bit quantites of fractions of a currency unit or a fixed point type. (Using an MP library to simulate BCD is overkill since a 64-bit integer has a greater mantissa than any financial system will ever need, even if calculating the National Debt to the penny)
On 32-bit systems that lack instructions like MMX/SSE/Altivec to handle 64-bit quantites, one might instead use a packed struct of two 32-bit quantites at appropriate currency divisions (US: dollars and ten thousandths of cents, JP: thousands and hundreths of Yen) can also work. The second method is more cumbersome but there are some nice tricks: like when summing you can get away with resolving the carry until outside of the loop as long as N < 1000 or so.
In any case packed structs are probably unnecessary on 32-bit architectures anymore because most compilers and scripting languages have a decent 64-bit emulation mode that is as good as any library implementation.
Fixed point isn't really necessary either. If you do calculations using 32-bit integers representing (cents/tenths/hundreths of cents) it works out quite well. I mean, do you need a cash register than can tally sums > $1000000?
Also it would be nice if we got a few more emulated devices supported. Maybe a gigabit ethernet adapter. A CDROM 'server' that allows you to attach and unattach ISOs (which might look like insert/remove events). The holy grail would be M on N threading. But I don't think that fits into his emulation model very cleanly.
There is an 8139too network target too (which is 100mbps), which should be more than acceptable, but I think you need to build Xen yourself to get it. Also, what of giving the guest OS it's own network card through a PCI mapping? I always have more onboard/outboard network controllers than I know what to do with in my servers. It's not the most transparent way of going about things but if you have a bandwidth-hogging virtual host to run...
Rather than you reading a document and extracting keywords or the "topic", the computer does it. Rather than you looking at a picture and identifying the people depicted, the computer does it.
It's getting the computer to do the things that we are too lazy to do: annotate the artifacts that we want to be able to retrieve later.
We have really shiny infrastructres with Web Services and SOA and brokers and all sorts of fun stuff that is all absolutely useless unless you pay a bunch of people to sit around and methodically go through all your stuff and mark it up.
Nobody wants to do that. Nobody wants to pay for that. It's all ass-backwards.
We should be focusing on how we can get the computer to do that for us. Or, alternatively, pioneer methods where metadata is captured at the time of content creation (or prompting the user at appropriate times to fill in some critical details) and propagated all the way into the final archived form. (Like EXIF tags in JPEGs or ID3 tags in MP3).
I stole the "tattoo" bit from a term used to describe how NT4.0 group policy used to work. Your Administrator would put registry settings in the NETLOGON share it would "tattoo" all over your host's settings, erasing whatever was there. You could go back in and undo the changes if you wanted to (they aren't persistant like Group Policy Objects) but it was as painful as getting "old ink" removed. The new GPOs are much better, they don't muck up your registry, they just overlay it. So it's like getting Henna or a press-on.
When a device initiates DMA and it is controlled by firmware, your precious precious memory is at the mercy of the firmware authors. And if the ink slinger (the firmware) gets schizo on your ass, well, you're waking up with a Unicorn impaling a baby on your left buttock.
And these black hatters are whispering in this guy's ear.
It may not be a firmware bug even, but an 802.11 _implementation_ bug that every vendor they've tried (thus far) seems to have included. Some kind of unhandled condition. And since nearly every wireless card out there is an ARM7 running some kind of firmware attached to a radio, all they need to do is leverage the implementation bug into a stack smashing exploit that works ON EVERY ARM EMBEDDED WIRELESS CARD. It is likely that there is a recursive function with a similar structure for multple firmwares (since they are all implementing a fixed protocol in similar embedded environments), which if can be tripped up by a malformed packet reliably, can be used as the common injection point for exploit code. So you've got ARM firmware exploit code, which uses a stack smash. You blast the wireless station with malformed packets attempting to get it to trip on the buffer overflow. If triggered it would in turn load (potentially) card specific host insertion code, which in turn injects OS specific exploit code into the host memory.
Boom: multi-card, multi-OS exploit. Thanks to the consistent firmware environment on each wireless station.
If they found a vulnerability in a common firmware used by more than 1 manufacturer (Proxim, Atheros, whatever), they could get any model wireless card to tattoo all over the host memory using DMA. Drivers have nothing to do with it. The vulnerability might be OS specific in that the payload and where it needs to go to exploit the system will vary from host OS to host OS.
The reason why "DC distribution" isn't being done is because the onus is on device manufacturers to all use the same kind of plugs for DC power-in and to use a restricted set of voltages. Manufacturers would rather provide an AC/DC converter that does exactly what the device needs and no more or no less.
But since most many devices are starting to support USB connectivity (music players, cameras, etc.) it would make sense if they could standardize on the USB connector itself to deliver power.
You can just buy a cheap powered USB hub as a mini-power strip to power usb-powerable devices.
I've actually seen a few devices that come with a DC->USB connector for just this purpose. It's usually desk toys from geek websites.
In a pinch i'll use a 3com, but using a Cisco switch with 3com can be painful if you're autodetecting speed/duplex.
Seriously. I swore off using 3Com cards once I ran into this and it never improved over a 2 year period. If it's so good how come it can't even manage to autonegotiate properly with the most common infrastructure switches? These chip-level issues that disturbed me, never mind that it was parallel-tasking or whatever. No software can fix broken wire protocol handling. Maybe Cisco were the ones screwing up but it never sat right and I never trusted their physical cards since.
And on the other side (Via, Realtek, etc.) it comes down to driver quality. I think the RealTek and Marvel hardware works just fine so long as you use the WHQL certified and generic linux drivers. Then it's rock solid and as low latency I could expect before some kinda fancy TCP offload.
And Intel cards always kick ass. I expect because they control the card manufacture and they source all the drivers. But they are expensive.:-(
Wireless is fine if you live in the middle of nowhere. But only so many devices can use the 900MHz, 2GHz, and 5GHz bands. Anyone who lives in suburbia or the city will know what I'm talking about. It's not like your mouse will start moving on its own, but when its doing a CDMA backoff because your nextdoor neighbor's cordless phone is in use, you'll bang it in frustration when you miss that headshot.
And forget about IR. Line of sight? It's a joke.
Anything _interactive_ needs to be wired. Speakers, monitors, keyboard, mouse. Wireless might be okay for a printer or your MP3 player -- devices that you do batch transfers with.
Plus, wireless input devices are _heavy_ and it can really take a toll on your wrist or forearm. Until we get lighter weight, efficient batteries that don't cost and arm and a leg and/or don't explode, it's another major drawback.
Nothing wrong with it intrinsically. But using AR for storing files in a file went out with a.out. It lacks some of the metadata that you can tack on with cpio or even tar (in that with tar you can always add your own custom record types since you control the libraries parsing it).
I guess I was just trying to pick on dpkg in a senseless way in the same way that people get mad at RPM because it's BINARY (oh no!) and using bare RPM they run into dependancy issues (use a higher level tool, durr).
ALWAYS label your volumes so they have UUIDs. Never put bare drives into a RAID. Partition them, set the drive-sized slice to 0xFD, and enjoy device name independance.
Actually the answer you are looking for is udev. You could name your disks via their serial# or some such but there are too many guides and documents and scripts out there that rely on the simple first-seen-first-labeled sd[abcde...] nomenclature that they aren't going to make that the default.
So, you have a problem with system-config-packages? Or up2date? Or yum?
Your struggling to understand the command line to rpm is equivalent to someone trying to do everything in Debian via raw dpkg commands.
I'm sorry if your struggles left a bad taste in your mouth but I wouldn't be caught dead using a package manager that uses the ARchive format behind the scenes. Talk about old and busted.
Slashdot Mirror
\(_o)/
It actually has effects felt outside the Internet.
Bands are now made and broken across Tom's goddamn friend list counts.
Movies like Step It Up rake in totally unexpected profits due to MySpace promotion.
Kids who would never get laid in HS 4 years ago are now gettin the hookup, dawg.
Its size dwarves LJ, Xanga, and the others.
Even I was coerced into getting a profile. ME! That says something.
(Then again I only use it to spy on other people)
4, 6) They were first.
5) Blogging HAS changed things. Not that I like that, but I accept it.
10) Slashdot was the first to do that PLUS a threaded discussion system that was 1) anonymous if you wanted 2) immune from moderators who could edit/delete contents
12) Craigslist was the first new site (not born of a oldworld BBS) that became the defacto BBS for whole cities. This was before "local" websites were all the rage.
I remember that.
Didn't it basically let you broadcast the presence of and search other member's NT shares?
SMB/RPC in the open over the Internet. Man, those were the days.
I seriously doubt these tests will ever come to pass. DARPA doesn't like to run tests that other scientifically advanced nations can detect and then point a damning finger at. They'd be more likely to fund research for high MeV particle resistant satellite and aircraft systems (since that has no noticeable external effects... keep the "advantage" secret)
And enjoy your cancer.
Multiplication is equivalent to a convolution of two discrete arrays.
It's a O(N^2) operation if done using the multiply, shift, add method.
An FFT (of which there are integer variations) is a O(N*log(N)) manipulation of the data.
When you transform both arrays, you do a straight component multiply, then you untransform the result.
3 * O(N log N) + O(N) O(N ^ 2) for very large multiplicands.
We're talking about way outside of the range of most scientific or financial applications. It's an important speedup for mathematical research and certain kinds of statistical analysis.
They are useful for storing decimal quantites unambigously in databases and flat files.
However they are not as useful for code that manipulates them heavily:
* MP libraries that use full-on binary representation are always faster and more memory efficient unless we're talking about an IBM mainframe
* It's a pain to up and downconvert from "normal" datatypes
In-memory representations are probably better served by 64-bit quantites of fractions of a currency unit or a fixed point type. (Using an MP library to simulate BCD is overkill since a 64-bit integer has a greater mantissa than any financial system will ever need, even if calculating the National Debt to the penny)
On 32-bit systems that lack instructions like MMX/SSE/Altivec to handle 64-bit quantites, one might instead use a packed struct of two 32-bit quantites at appropriate currency divisions (US: dollars and ten thousandths of cents, JP: thousands and hundreths of Yen) can also work. The second method is more cumbersome but there are some nice tricks: like when summing you can get away with resolving the carry until outside of the loop as long as N < 1000 or so.
In any case packed structs are probably unnecessary on 32-bit architectures anymore because most compilers and scripting languages have a decent 64-bit emulation mode that is as good as any library implementation.
Fixed point isn't really necessary either.
If you do calculations using 32-bit integers representing (cents/tenths/hundreths of cents) it works out quite well.
I mean, do you need a cash register than can tally sums > $1000000?
... is old hat. We know how to do that, and we can do it easily.
But z/VM can't virtualize Windows.
That's what we're trying to do within an infrastructure that we control.
IBM can't help us there.
Also it would be nice if we got a few more emulated devices supported. Maybe a gigabit ethernet adapter. A CDROM 'server' that allows you to attach and unattach ISOs (which might look like insert/remove events).
The holy grail would be M on N threading. But I don't think that fits into his emulation model very cleanly.
There is an 8139too network target too (which is 100mbps), which should be more than acceptable, but I think you need to build Xen yourself to get it.
Also, what of giving the guest OS it's own network card through a PCI mapping? I always have more onboard/outboard network controllers than I know what to do with in my servers. It's not the most transparent way of going about things but if you have a bandwidth-hogging virtual host to run...
Glad you don't work in marketing :)
Me too.
Metadata synthesis:
Rather than you reading a document and extracting keywords or the "topic", the computer does it.
Rather than you looking at a picture and identifying the people depicted, the computer does it.
It's getting the computer to do the things that we are too lazy to do: annotate the artifacts that we want to be able to retrieve later.
We have really shiny infrastructres with Web Services and SOA and brokers and all sorts of fun stuff that is all absolutely useless unless you pay a bunch of people to sit around and methodically go through all your stuff and mark it up.
Nobody wants to do that. Nobody wants to pay for that. It's all ass-backwards.
We should be focusing on how we can get the computer to do that for us. Or, alternatively, pioneer methods where metadata is captured at the time of content creation (or prompting the user at appropriate times to fill in some critical details) and propagated all the way into the final archived form. (Like EXIF tags in JPEGs or ID3 tags in MP3).
I stole the "tattoo" bit from a term used to describe how NT4.0 group policy used to work.
Your Administrator would put registry settings in the NETLOGON share it would "tattoo" all over your host's settings, erasing whatever was there.
You could go back in and undo the changes if you wanted to (they aren't persistant like Group Policy Objects) but it was as painful as getting "old ink" removed.
The new GPOs are much better, they don't muck up your registry, they just overlay it. So it's like getting Henna or a press-on.
When a device initiates DMA and it is controlled by firmware, your precious precious memory is at the mercy of the firmware authors. And if the ink slinger (the firmware) gets schizo on your ass, well, you're waking up with a Unicorn impaling a baby on your left buttock.
And these black hatters are whispering in this guy's ear.
Wow I can really stretch an analogy out. GO ME
It may not be a firmware bug even, but an 802.11 _implementation_ bug that every vendor they've tried (thus far) seems to have included. Some kind of unhandled condition.
And since nearly every wireless card out there is an ARM7 running some kind of firmware attached to a radio, all they need to do is leverage the implementation bug into a stack smashing exploit that works ON EVERY ARM EMBEDDED WIRELESS CARD. It is likely that there is a recursive function with a similar structure for multple firmwares (since they are all implementing a fixed protocol in similar embedded environments), which if can be tripped up by a malformed packet reliably, can be used as the common injection point for exploit code.
So you've got ARM firmware exploit code, which uses a stack smash. You blast the wireless station with malformed packets attempting to get it to trip on the buffer overflow. If triggered it would in turn load (potentially) card specific host insertion code, which in turn injects OS specific exploit code into the host memory.
Boom: multi-card, multi-OS exploit. Thanks to the consistent firmware environment on each wireless station.
If they found a vulnerability in a common firmware used by more than 1 manufacturer (Proxim, Atheros, whatever), they could get any model wireless card to tattoo all over the host memory using DMA. Drivers have nothing to do with it.
The vulnerability might be OS specific in that the payload and where it needs to go to exploit the system will vary from host OS to host OS.
The reason why "DC distribution" isn't being done is because the onus is on device manufacturers to all use the same kind of plugs for DC power-in and to use a restricted set of voltages.
Manufacturers would rather provide an AC/DC converter that does exactly what the device needs and no more or no less.
But since most many devices are starting to support USB connectivity (music players, cameras, etc.) it would make sense if they could standardize on the USB connector itself to deliver power.
You can just buy a cheap powered USB hub as a mini-power strip to power usb-powerable devices.
I've actually seen a few devices that come with a DC->USB connector for just this purpose. It's usually desk toys from geek websites.
In a pinch i'll use a 3com, but using a Cisco switch with 3com can be painful if you're autodetecting speed/duplex.
:-(
Seriously. I swore off using 3Com cards once I ran into this and it never improved over a 2 year period. If it's so good how come it can't even manage to autonegotiate properly with the most common infrastructure switches? These chip-level issues that disturbed me, never mind that it was parallel-tasking or whatever. No software can fix broken wire protocol handling. Maybe Cisco were the ones screwing up but it never sat right and I never trusted their physical cards since.
And on the other side (Via, Realtek, etc.) it comes down to driver quality. I think the RealTek and Marvel hardware works just fine so long as you use the WHQL certified and generic linux drivers. Then it's rock solid and as low latency I could expect before some kinda fancy TCP offload.
And Intel cards always kick ass. I expect because they control the card manufacture and they source all the drivers. But they are expensive.
Why not focus on metadata synthesis techniques instead of gigantic infrastructures lumbering under their own weight with nothing to plug into them?
Wireless is fine if you live in the middle of nowhere.
But only so many devices can use the 900MHz, 2GHz, and 5GHz bands. Anyone who lives in suburbia or the city will know what I'm talking about.
It's not like your mouse will start moving on its own, but when its doing a CDMA backoff because your nextdoor neighbor's cordless phone is in use, you'll bang it in frustration when you miss that headshot.
And forget about IR. Line of sight? It's a joke.
Anything _interactive_ needs to be wired. Speakers, monitors, keyboard, mouse. Wireless might be okay for a printer or your MP3 player -- devices that you do batch transfers with.
Plus, wireless input devices are _heavy_ and it can really take a toll on your wrist or forearm. Until we get lighter weight, efficient batteries that don't cost and arm and a leg and/or don't explode, it's another major drawback.
And that would explain why they are decent.
You want one of the following (in order of desirability):
1) Intel
2) Marvel
3) Via/Rhine
4) RealTek
And fuck the rest.
Yes, fuck Broadcomm and their shitty SMP-deficient drivers.
Nothing wrong with it intrinsically. But using AR for storing files in a file went out with a.out.
It lacks some of the metadata that you can tack on with cpio or even tar (in that with tar you can always add your own custom record types since you control the libraries parsing it).
I guess I was just trying to pick on dpkg in a senseless way in the same way that people get mad at RPM because it's BINARY (oh no!) and using bare RPM they run into dependancy issues (use a higher level tool, durr).
ALWAYS label your volumes so they have UUIDs.
l #sysfsmatch
Never put bare drives into a RAID. Partition them, set the drive-sized slice to 0xFD, and enjoy device name independance.
Actually the answer you are looking for is udev. You could name your disks via their serial# or some such but there are too many guides and documents and scripts out there that rely on the simple first-seen-first-labeled sd[abcde...] nomenclature that they aren't going to make that the default.
Check this out:
http://www.reactivated.net/writing_udev_rules.htm
So, you have a problem with system-config-packages?
Or up2date? Or yum?
Your struggling to understand the command line to rpm is equivalent to someone trying to do everything in Debian via raw dpkg commands.
I'm sorry if your struggles left a bad taste in your mouth but I wouldn't be caught dead using a package manager that uses the ARchive format behind the scenes. Talk about old and busted.