I must ask: what have you been smoking?
on
Slash 2.0 Released
·
· Score: 2
You say "Slash reduced it to about 4MB free". Question: how are you measuring "free" memory?
Are you sure you aren't making the fairly common mistake of misunderstanding how a *nix machine uses memory? The natural state of any *nix machine is to have very little "free" memory: that which is not in use by processes is used to buffer the disk system. For example, the system I am using this very moment has 640M of memory (and that should be enough for anybody;^) of which 8123K is free. However, most of that memory, 506M to be exact (to 3 significant digits base 10) is being used to buffer the disk system.
Could it simply be that Slash touches more of the file system, causing the disk cache to consume more otherwise idle memory?
Or, were you indeed reporting the combined totals of free memory and disk cache memory?
Now, if only RedHat (or SGI) would integrate support for installing to an XFS filesystem on an LVM volume.
For those of you who don't know what LVM is: with LVM, you make a disk into a pile of storage blocks, then you put those blocks into a pool. That pool is a block device, and you can create a file system on it.
The nice thing is that you can add blocks from many different drives into the pool, so a volume can span multiple physical disks. Need more space on root? Just pop a new disk into the system, add it to the pool, and expand the XFS filesystem into the new space. All without losing any data (indeed, even without downing the system...)
This is different from RAID in that with RAID, you cannot add disks to the array and get more storage. You can add more disks to serve as hot spares, but you don't get any more space without rebuilding the array (and losing your data).
Of course, the best thing is RAID-->LVM-->XFS, but....
For those of you who don't know who www.comso.org is (the URL of the link above), the Kansas Cosmosphere and Space center is a space museum here in Kansas (Hutchinson, to be exact) that has the largest collection of Russian space hardware outside Russia itself. It's where NASA sends its astronauts to train on Russian space hardware, where Ron Howard and Tom Hanks went to get the space hardware for their movies, where just about every museum in the world sends their space hardware for preservation work.
I'd always said that I expected Max to be out in the Pacific with a big catcher's mitt when MIR came down. I wouldn't be too surprised if Max got in on this bid.
Assuming, of course, that it is real, and not a hoax...
Uhh, Rob, why do you care what the weather is like outside? Do you even go outside?;^)
However, the biggest problem with this sort of dream is that it means the manufacturers must surrender control: the video manufacturers must surrender control to you of their content, the various hardware manufacturers must surrender control to you of their hardware. They no longer can lock you into their hardware (You must have a Sony TV and Sony VCR and Sony DirectTivo and Sony Stereo and Sony....).
Furthur, what happens when a bunch of people set up a system whereby you can distribute when the commercials start and stop in a program. Then, skipping commercials becomes automatic.
Unless the sheeple demand these features (like that will happen: "What's perl?"), it won't happen.
My BS and scam detectors burned out about three sentences into the guy's offer. "Give me $100 and I *might* give you $5000"? That is a classic scam, a variant of the "Give me $1000 ernest money and I'll split this $10000" scam.
Sorry, but technical details aside, anyone who responded to this should avoid timeshare offers, Ginsu knife commercials, and Three Card Monty players.
First, the base station manufacturers don't have the hardware ready to deploy. Among other reasons, they have no good way to test the equipment. 3G uses some very advanced modulation techniques, and you cannot just slap a power meter on the finals and tune for maximum.
Second, the handset manufacturers are not yet ready with the final version of the handsets. The software protocols are complex, and hard to test.
Lastly, once the first and second problems are licked, the celluar providers have to roll the systems out. A cell site costs several million [$£]s, and you need lots.
Of course, it doesn't help that the frequency band allocated to 3G in Europe is different than the frequency band allocated in the US than the frequency band allocated in Japan....
I disagree that it is not newsworthy. I was having this very problem, and this article helped me correct it.
True, it does say in the kernel configuration that this option might get you into trouble. So do several options. What the kernel help doesn't say is any good way to tell that ECN is giving you problems. No diagnostic measures to try in the event of problems.
Some of us like to try new things. We like to see what happens if we enable a feature, because we like to find bugs and squash them. Many people who are running Linux just want a stable system to work with, and that's good. However, those of us who remember what it was like before Linux went mainstream want to continue to push the envelope.
Actually, the behavior he is describing is what is actually implemented in most cases.
During the base class constructor, the virtual function table pointer is initialized to point to the base class table, thus when the user written ctor code is called any virtual function ref will be to the base class ctor.
When the next level of inheritance's ctor is called, the VTPTR will be initialized to the derived class VTBL, and so any virtual will go to the virtual class.
During destruction, the process is reversed.
All that is needed is to formalize this behavior.
Now, there is a problem related to this that I'd like to see addressed:
Consider a base class which exists to allow an object to attach to a list and have a virtual method called in response to events sent to that list. It is up to the derived class to overload a virtual function to handle those events.
Now, ideally I'd like the base class to connect to the list in the ctor, and disconnect in the dtor. However, it is not safe to connect to the list until the object is fully constructed, as an asynchronous event may cause the virtual method to be called before the object is constructed. Equally, I want the object off the list before the dtor is called for the same reason.
What I'd like to have would be an additional two methods. The first would be called immediately after the ctor, the second immediately before the dtor. Thus, these calls have at their disposal the whole, fully constructed object, with all virtual methods intact and ready to go.
In the case of global objects or static objects, the compiler would generate a second list of function calls, to be called after the init code has iterated through all the static constructors (and another to be called before iterating over all static destructors).
In the case of auto objects or dynamic objects, the call would be made after the object was constructed.
This solves not only the above problem, but also it helps to solve the problem of circular dependances in construction ( a needs b to construct, b needs c, c needs a). The best way to avoid this design error is to do as little in the ctor as possible, and push the heavy lifting off to a second function. This method gives you that second function.
Having done a fair bit of multithreaded C++, I am of the opinion that, if they are going to standardize on a threading library, they are going to need this sort of hook.
Well, to embrace and extend the analogy you made in your article:
<Devil's Advocate>
What AOL did was to create a spa, and unlock their back door (TOC), and allow the neighborhood kids in to use the bathroom, the phone, and maybe get a little sugarwater to drink. The front door (OSCAR) was for paying guests.
You argue that, since they've left the back door open, you ought to be allowed to use the front door, the microwave, and the bigscreen TV as well.
Now, AOL's stopped putting sugarwater out, they've turned off the phone, and once in a while the toilet won't flush. They are focusing on the paying guests to the detriment of the neighborhood kids. You argue that this merely increases your right to use the front door.
</Devil's Advocate>
I'm just playing Devil's Advocate here: I dislike what AOL is doing, and I'm just trying to make sure that your arguements for them allowing OSCAR access to all are as sound as possible. The arguement you made in your article, to me, seems a little shaky, and I just wish to help strengthen it.
<Op-ed>
I dislike AOL's tactics. Like many other companies, they have managed to create a monopoly de facto if not de jure, and are moving to extend it. This is really dumb on their part: making IM work for all increases the value of their network under Metcalfe's law, as well as making them less likely to attract the DOJ's attention.
</Op-ed>
I guess they feel the DOJ is a toothless tiger...
The assertion is that, since AOL has released TOC to general use, that obviates their claim on their server resources. It states that, until AOL removes TOC, they cannot claim they are simply restricting access to "authorized users" since they have implicitly authorized everybody.
Yet, the article continues by pointing out that TOC has lost features. The only way this can happen is if AOL removes those features from the TOC servers.
Now, if AOL wished to remove TOC, they would have to do this by disabling capabilites at the server. Is this not what they have already done?
I'm not defending AOL's actions: they have a monopoly and are moving to preserve and extend it. It seems to me they are perilously close to violating the Sherman act. Are there any lawyers who which to comment?
If you're going to wage war on direct marketing, wage it on all fronts: telemarketing, direct mail, direct email. There's no need to single out email.
Yes, let's wage the war on all fronts. I'd support making telemarketing, direct mail, and spam all opt-in.
For telemarketing, it's already quite feasible. Just add a record to my data in the telco switch setup, next to the "block 900 calls" and "block collect calls" fields, that says "block telemarketing calls". Add a record to the telemarketer's entry indicating they are a telemarketer (this actually already exists, it's called "subscriber service class" and is a part of Signaling System 7 (what the phone system uses)), and problem solved.
Ditto for snail mail: allow me to have the USPS set a flag over my box that says "no junk", and have them mark all junk "return to sender, recepient refuses bulk mail" (and charge their account for postage).
Back these up with some strong policies that prohibit abuse (telco's will shut off the idiots who telemarket from home, USPS will terminate the third-class accounts of companies that don't correctly mark their mail as bulk advertising, ISPs will terminate charge abusers...)
NOTE: Not once in the above did I advocate making LAWS. I am for policies enforced by the private sector (and the USPS, dispite the name, is nominally private sector now.)
sllort, I cannot help but notice that you do not list your company in your/. info, that your email is a throwaway account, and that you don't say who you represent in your posting. If direct marketing is so good, why don't you allow it to happen to you?
I2O uses an abstraction of specific pieces of hardware: a disk controller exports a specified set of registers that the system writes to. Those registers are read by a CPU on the card, which then handles the operation.
It's very similar to the design of I/O in a mainframe: you have a smart I/O device, and it just interrupts the main CPU when it actually has real data to move.
However, while this is great for storage and network cards, it does very little for video or oddball cards. It also raises the cost of the card by tens of dollars as you must use an Intel i960 microprocessor to implement the I2O interface.
Of course the really funny thing is that the i960 has a Linux port to it, which means your disk controller card could also boot a kernel....
The question I have is, will this new bus be CPU neutral?
Consider PCI: There is no spec for what the bootrom of the card will contain. Usually, it contains only Intel x86 real mode code. The prevents the card from being used as-is in anything else: Your Alpha, your iMac, your Sun, all are out of luck when you plug this card in (unless they have x86 emulators to run the boot code.)
How about we put some thought into something like Sun's OpenFirmware system: a small, simple virtual machine spec to initialize the card and provide any functions needed to boot.
Realize: many cards wouldn't need this. Only video, storage and network cards would need to have a driver (to allow the boot process to begin.) Once the OS, whatever it was, got loaded, it could then load native drivers for the card if they existed.
And even if the drivers don't exist: slow and working is better than not working at all. I'd rather be able to get my new floobySCSI card working, albeit slowly, then have a new paperweight.
Lastly, since the purpose of this VM is very focused, it can provide very high-level operations to the system. It can have instructions like "Configure DMA from here to there", "Move a potload of data from here to there", "On interrupt #n do this...", and those micro-ops would be in the native machine code in the VM implementation. Thus, a card's VM driver could be pretty close to optimal anyway.
However, this idea does two things that doom it:
It allows non-Intel systems to not be second class citizens.
It allows non-Microsoft OSs to not be second class citizens.
As a result, kiss the support of the two big players you need goobye.
Well, it's certainly within the bounds of what is possible.
As for impedance: being a piezo device, they probably like lots of voltage and little current, ergo they are high impedance devices.
The problem with bass response is easy to see: imaging stretching a sheet of plastic wrap across your window frame. Turn your stereo on inside, and go outside to listen. Now, the sound will be about as good as your stereo, because the plastic wrap will be moving a fair amount back and forth, moving a lot of air.
For these speakers to do the same thing, they are going to have to be able to flex quite a bit to move enough air to make good bass. The problem is finding a piezoelectric substance that will flex that much without cracking. However, if they are using a polymer instead of a crystalline material, they may have a chance.
What if I'm not running on a system that supports Flash? Am I blocked from seeing your site? Or do I get to go straight on in, avoiding the ad?
What if I write a "Flash" plug-in that says "Yeah yeah yeah, I've show the ad, now let me in"?
Actually, I'd LOVE a subscription service that allowed me access to a fast server, no ads, and no intrusion into my personal life. Don't try to track me, just give me a way to get in (passwords e-mailed to my account that expire in a short period of time (with no spam as baggage?)) and let me go.
The only way to exploit this is if the FTP client is under the attacker's control, and passing through the firewall. This breaks down into two possible catagories:
The firewall is protecting an FTP server. In this case the attacker can connect to the server and punch holes in the firewall.
The attacker is on the inside of the firewall, and has FTP access out.
Case 1 is the most scare from a sysad standpoint: if I had set up a world-accessible FTP server protected by a Linux firewall, the world could punch holes in my firewall.
Case 2 would be more the case of a company that chose to limit employees' access to the Internet, and the employees could use this to punch holes in the firewall. This is not as much a security risk (if you have employees who are security risks, you need to identify them and fire them.) After all, if one of your employees controls a server outside the firewall, he can always set up a proxy server on port 80 and do whatever he wants.
Still, I'm glad this sort of thing was caught and corrected. This is why peer review is important for security....
In an already constructed house, you may be able to pull new wire along with already existing wire. For example, I was able to pull my network cable and audio/video cable alongside the existing TV RF co-ax.
Here's the proceedure:
Remove the wallplate for the existing cable.
Remove the cable from the wallplate and tie a small nylon cord to the cable.
TAPE IT with electrician's tape. Don't use duct tape: its surface is far to sticky. Electrician's tape is much slicker. Start from the end that will go into the wall first, and wrap back tightly. Don't add more than two layers of tape to any spot (in other words, overlap not more than once).
Now, have your buddy go to the other end of the cable, and GENTLY pull the cable while you feed the cord into the wall. Eventually, your buddy will get the cord.
Have your buddy tie another cord onto the first, along with the cable you just pulled out, and any new cables you want to pull.
Don't tie all the cables on in the same place: stagger them by about a foot or two. Tape their ends as above: start at the end that will go in the wall first, and keep things smooth and snag-resistant.
Don't get too ridiculous with the number of cables you pull in this step: one or two additional cables at most, until you get a feel for what you are doing.
Now, you gently pull on the cord, while your buddy feeds the cables in. Eventually, you will get the end of the first cable out, along with the cord your buddy tied on.
If things snag, give your buddy slack and have him pull things back a few feet, and try again.
When you have the ends of all the cables pulled out, tie off the cord your buddy tied on so that it won't fall back through.
Repeat as needed
You ALWAYS leave a cord pulled in line, so that the next time you can just tie onto the cord and start pulling.
Also, the number of cables you can pull will depend upon how big a hole the original installers made in the joists: if they left a nice, 1 inch hole you can pull quite a bit of cable. If they just bored a hole big enough for what they were pulling, you are out of luck unless you can get access to drill larger holes.
Lastly, DON'T MIX LOW VOLTAGE LINES AND POWER LINES! Don't try to pull Ethernet, video, or RF cable through the same holes as power unless you like frying your gear, electrocuting yourself, or burning down your house and not having insurance cover it.
The DUL is only and explicitly for the purpose of denying access based on the degree of connection the users can afford
This is patentely wrong! The MAPS DUL does not discriminate against dial-up users, as they can send mail to whomever they want. Nor do the users of the DUL discriminate. If you want to send mail to someone, use your ISP's mailservers! That's what they are there for.
Consider: if you send email to George, and George's mailserver is down for a day because of Jethro and his backhoe, what happens:
Scenario A - you are sending the mail directly: Your client must connect every hour or so, and try to get to George's server, tying up your modem and phone line.
Scenario B - you are sending via your ISP's mailserver: You connect and send the message to your ISP's server. It then tries every hour until they get George's connection fixed, and you go about your merry way.
Which of these scenarios makes more sense?
Come on, I was on a dial-up for years, and I just tell my boxen to forward to my ISP's mailserver. It's not that hard, it saves me bandwidth, it just makes sense.
And for the argument that your ISP's mailservers suck: If your ISP cannot run its mailservers reliably, is your connection going to be any more reliable?
And for the argument that you wish to use somebody else's mailserver to receive mail: YOU CAN. Using your ISP's server to SEND your mail doesn't prevent you from retrieving your mail from some other server: that's why mail goes OUT on SMTP and comes IN on POP3/IMAP!
Lastly, for the argument that the DUL doesn't reduce SPAM: My ISP just went to using DUL filtering. My spam went from ten a day to one every couple of days.
All this info about GIS is nice, but it seems to me to be a little high-end: it's not aimed at the needs of the average user.
What I would like to see is somebody making an application like Delorme's AAA MapNGo or Microsoft's Streets and Trips available.
However, those sorts of programs are difficult to do under the Free Software model. The code isn't hard (no harder than a browser or game engine) but the program is worthless without data. And, unlike a program which you can stay in your little room and write, data requires you to have detailed maps of street locations and interconnections, locations of attractions, hotels, restaurants, and gas stations. You cannot just sit in your room and hack those out.
Now, if we could just persuade Delorme that the Free Software community is a good market...
What are you running for your packet link: 2400 or 9600? Given that packet is simplex, CD/CSMA, and requires the keyup and keydown delays for turn-arounds, I'd think TCP/IP would be unacceptably slow.
Also, how do you prevent the 5|r!p7 |1ddi3z from sending unacceptable things over the link?
If I could come up with good solutions to these problems myself, I'd be tempted to set my station back up.
I'm a bit disappointed with Bob's answer to my question. Basically, he's taking a "If you build it, they will come" attitude to hardware support. I can think of another company that took that attitude with their computer product.
Its name was Atari.
True, many hardware vendors are supporting Linux, many more than yesterday. However, I still have my Minolta DimageII film scanner that Linux won't recognize, a Neo45 MP3 system Linux cannot talk to, and my Voodoo 3500 that Linux cannot reliably control the tuner on (although I DO get damn good framerates with XFree 4.01 DRI).
If RH were to assign a programmer to making V4L support the V3500 tuner, a programmer to making the USB->SCSI driver work reliably on the Minolta, and getting the USB->IDE interface in the Neo working, they could have that in about three man-months each. Plus, with a good framework for SCSI->USB and IDE->USB, then other people could add support. RH could act as a catylist.
(Before you say "Stop talking and start coding" - I'd love to, and I plan on it. However, I have a new house to pay for, so I have to work for a living. I cannot devote the 10 hours/day it takes to make good progress on this sort of project. Perhaps in my younger days in college... but not now.)
The changes for SELinux have NOTHING to do with the network transport of data! They will in no way make it either easier or harder for the NSA to monitor network traffic!
SELinux is simply about making the data on your machine safe from other processes on your machine. It prevents a program from accessing any resource on the machine it is not cleared for, no matter who the process is running as.
OK, let's put on our paranoid hats <SoundFX type="crinkling aluminum foil"> and try to guess what benefit this has to the NSA: It makes it possible to use Linux in a secure environment. It gives them an OS for which they have source code (I am pretty sure they have the source for Windows(9*|NT|XP|2000) and Solaris, legally aquired), but they have the legal right to modify and distribute. This allows them to secure any government agency's computing resources in a consistant fashion. Remember, part of their job is securing OUR stuff.
Now, I'm sure that if a modification to allow all TCP traffic to be encrypted by default were to be added to normal IPv4, they might have a problem with that, since that would interfere with their normal data gathering operations. BUT, hardening Linux so a Trojan/Malicious user cannot get access to somebody else's stuff is going to make their life EASIER.
Remember, if the NSA wanted what is on your hard drive, they'd just wait till you were out, pick your locks, dd the drive, and leave.
True, in a system like this the effects of orbital mechanics would be more obvious. However, they would also be a lot harder to characterize. Consider our calendar system: months are easy, weeks are just quarter months. Now, in a moon of a gas giant, what would you use? Even if you pick the most obvious "moon", it's period as viewed from your world wouldn't be a constant.
It would be very hard to develop mathematics in this world.
If you've never read "Nightfall" by Isaac Asimov, I suggest you do so. The Good Doctor covers this item in great detail.
Slashdot Mirror
You say "Slash reduced it to about 4MB free". Question: how are you measuring "free" memory?
;^) of which 8123K is free. However, most of that memory, 506M to be exact (to 3 significant digits base 10) is being used to buffer the disk system.
Are you sure you aren't making the fairly common mistake of misunderstanding how a *nix machine uses memory? The natural state of any *nix machine is to have very little "free" memory: that which is not in use by processes is used to buffer the disk system. For example, the system I am using this very moment has 640M of memory (and that should be enough for anybody
Could it simply be that Slash touches more of the file system, causing the disk cache to consume more otherwise idle memory?
Or, were you indeed reporting the combined totals of free memory and disk cache memory?
Now, if only RedHat (or SGI) would integrate support for installing to an XFS filesystem on an LVM volume.
For those of you who don't know what LVM is: with LVM, you make a disk into a pile of storage blocks, then you put those blocks into a pool. That pool is a block device, and you can create a file system on it.
The nice thing is that you can add blocks from many different drives into the pool, so a volume can span multiple physical disks. Need more space on root? Just pop a new disk into the system, add it to the pool, and expand the XFS filesystem into the new space. All without losing any data (indeed, even without downing the system...)
This is different from RAID in that with RAID, you cannot add disks to the array and get more storage. You can add more disks to serve as hot spares, but you don't get any more space without rebuilding the array (and losing your data).
Of course, the best thing is RAID-->LVM-->XFS, but....
I wonder if Max Ary reads Slashdot....
For those of you who don't know who www.comso.org is (the URL of the link above), the Kansas Cosmosphere and Space center is a space museum here in Kansas (Hutchinson, to be exact) that has the largest collection of Russian space hardware outside Russia itself. It's where NASA sends its astronauts to train on Russian space hardware, where Ron Howard and Tom Hanks went to get the space hardware for their movies, where just about every museum in the world sends their space hardware for preservation work.
I'd always said that I expected Max to be out in the Pacific with a big catcher's mitt when MIR came down. I wouldn't be too surprised if Max got in on this bid.
Assuming, of course, that it is real, and not a hoax...
Uhh, Rob, why do you care what the weather is like outside? Do you even go outside? ;^)
However, the biggest problem with this sort of dream is that it means the manufacturers must surrender control: the video manufacturers must surrender control to you of their content, the various hardware manufacturers must surrender control to you of their hardware. They no longer can lock you into their hardware (You must have a Sony TV and Sony VCR and Sony DirectTivo and Sony Stereo and Sony....).
Furthur, what happens when a bunch of people set up a system whereby you can distribute when the commercials start and stop in a program. Then, skipping commercials becomes automatic.
Unless the sheeple demand these features (like that will happen: "What's perl?"), it won't happen.
My BS and scam detectors burned out about three sentences into the guy's offer. "Give me $100 and I *might* give you $5000"? That is a classic scam, a variant of the "Give me $1000 ernest money and I'll split this $10000" scam.
Sorry, but technical details aside, anyone who responded to this should avoid timeshare offers, Ginsu knife commercials, and Three Card Monty players.
There are several problems with 3G deployment.
....
First, the base station manufacturers don't have the hardware ready to deploy. Among other reasons, they have no good way to test the equipment. 3G uses some very advanced modulation techniques, and you cannot just slap a power meter on the finals and tune for maximum.
Second, the handset manufacturers are not yet ready with the final version of the handsets. The software protocols are complex, and hard to test.
Lastly, once the first and second problems are licked, the celluar providers have to roll the systems out. A cell site costs several million [$£]s, and you need lots.
Of course, it doesn't help that the frequency band allocated to 3G in Europe is different than the frequency band allocated in the US than the frequency band allocated in Japan
I disagree that it is not newsworthy. I was having this very problem, and this article helped me correct it.
True, it does say in the kernel configuration that this option might get you into trouble. So do several options. What the kernel help doesn't say is any good way to tell that ECN is giving you problems. No diagnostic measures to try in the event of problems.
Some of us like to try new things. We like to see what happens if we enable a feature, because we like to find bugs and squash them. Many people who are running Linux just want a stable system to work with, and that's good. However, those of us who remember what it was like before Linux went mainstream want to continue to push the envelope.
Actually, the behavior he is describing is what is actually implemented in most cases.
During the base class constructor, the virtual function table pointer is initialized to point to the base class table, thus when the user written ctor code is called any virtual function ref will be to the base class ctor.
When the next level of inheritance's ctor is called, the VTPTR will be initialized to the derived class VTBL, and so any virtual will go to the virtual class.
During destruction, the process is reversed.
All that is needed is to formalize this behavior.
Now, there is a problem related to this that I'd like to see addressed:
Consider a base class which exists to allow an object to attach to a list and have a virtual method called in response to events sent to that list. It is up to the derived class to overload a virtual function to handle those events.
Now, ideally I'd like the base class to connect to the list in the ctor, and disconnect in the dtor. However, it is not safe to connect to the list until the object is fully constructed, as an asynchronous event may cause the virtual method to be called before the object is constructed. Equally, I want the object off the list before the dtor is called for the same reason.
What I'd like to have would be an additional two methods. The first would be called immediately after the ctor, the second immediately before the dtor. Thus, these calls have at their disposal the whole, fully constructed object, with all virtual methods intact and ready to go.
In the case of global objects or static objects, the compiler would generate a second list of function calls, to be called after the init code has iterated through all the static constructors (and another to be called before iterating over all static destructors).
In the case of auto objects or dynamic objects, the call would be made after the object was constructed.
This solves not only the above problem, but also it helps to solve the problem of circular dependances in construction ( a needs b to construct, b needs c, c needs a). The best way to avoid this design error is to do as little in the ctor as possible, and push the heavy lifting off to a second function. This method gives you that second function.
Having done a fair bit of multithreaded C++, I am of the opinion that, if they are going to standardize on a threading library, they are going to need this sort of hook.
Well, to embrace and extend the analogy you made in your article:
<Devil's Advocate>
What AOL did was to create a spa, and unlock their back door (TOC), and allow the neighborhood kids in to use the bathroom, the phone, and maybe get a little sugarwater to drink. The front door (OSCAR) was for paying guests.
You argue that, since they've left the back door open, you ought to be allowed to use the front door, the microwave, and the bigscreen TV as well.
Now, AOL's stopped putting sugarwater out, they've turned off the phone, and once in a while the toilet won't flush. They are focusing on the paying guests to the detriment of the neighborhood kids. You argue that this merely increases your right to use the front door.
</Devil's Advocate>
I'm just playing Devil's Advocate here: I dislike what AOL is doing, and I'm just trying to make sure that your arguements for them allowing OSCAR access to all are as sound as possible. The arguement you made in your article, to me, seems a little shaky, and I just wish to help strengthen it.
<Op-ed>
I dislike AOL's tactics. Like many other companies, they have managed to create a monopoly de facto if not de jure, and are moving to extend it. This is really dumb on their part: making IM work for all increases the value of their network under Metcalfe's law, as well as making them less likely to attract the DOJ's attention.
</Op-ed>
I guess they feel the DOJ is a toothless tiger...
I see one small problem with the article:
The assertion is that, since AOL has released TOC to general use, that obviates their claim on their server resources. It states that, until AOL removes TOC, they cannot claim they are simply restricting access to "authorized users" since they have implicitly authorized everybody.
Yet, the article continues by pointing out that TOC has lost features. The only way this can happen is if AOL removes those features from the TOC servers.
Now, if AOL wished to remove TOC, they would have to do this by disabling capabilites at the server. Is this not what they have already done?
I'm not defending AOL's actions: they have a monopoly and are moving to preserve and extend it. It seems to me they are perilously close to violating the Sherman act. Are there any lawyers who which to comment?
Yes, let's wage the war on all fronts. I'd support making telemarketing, direct mail, and spam all opt-in.
For telemarketing, it's already quite feasible. Just add a record to my data in the telco switch setup, next to the "block 900 calls" and "block collect calls" fields, that says "block telemarketing calls". Add a record to the telemarketer's entry indicating they are a telemarketer (this actually already exists, it's called "subscriber service class" and is a part of Signaling System 7 (what the phone system uses)), and problem solved.
Ditto for snail mail: allow me to have the USPS set a flag over my box that says "no junk", and have them mark all junk "return to sender, recepient refuses bulk mail" (and charge their account for postage).
Back these up with some strong policies that prohibit abuse (telco's will shut off the idiots who telemarket from home, USPS will terminate the third-class accounts of companies that don't correctly mark their mail as bulk advertising, ISPs will terminate charge abusers...)
NOTE: Not once in the above did I advocate making LAWS. I am for policies enforced by the private sector (and the USPS, dispite the name, is nominally private sector now.)
sllort, I cannot help but notice that you do not list your company in your
I2O uses an abstraction of specific pieces of hardware: a disk controller exports a specified set of registers that the system writes to. Those registers are read by a CPU on the card, which then handles the operation.
It's very similar to the design of I/O in a mainframe: you have a smart I/O device, and it just interrupts the main CPU when it actually has real data to move.
However, while this is great for storage and network cards, it does very little for video or oddball cards. It also raises the cost of the card by tens of dollars as you must use an Intel i960 microprocessor to implement the I2O interface.
Of course the really funny thing is that the i960 has a Linux port to it, which means your disk controller card could also boot a kernel....
Consider PCI: There is no spec for what the bootrom of the card will contain. Usually, it contains only Intel x86 real mode code. The prevents the card from being used as-is in anything else: Your Alpha, your iMac, your Sun, all are out of luck when you plug this card in (unless they have x86 emulators to run the boot code.)
How about we put some thought into something like Sun's OpenFirmware system: a small, simple virtual machine spec to initialize the card and provide any functions needed to boot.
Realize: many cards wouldn't need this. Only video, storage and network cards would need to have a driver (to allow the boot process to begin.) Once the OS, whatever it was, got loaded, it could then load native drivers for the card if they existed.
And even if the drivers don't exist: slow and working is better than not working at all. I'd rather be able to get my new floobySCSI card working, albeit slowly, then have a new paperweight.
Lastly, since the purpose of this VM is very focused, it can provide very high-level operations to the system. It can have instructions like "Configure DMA from here to there", "Move a potload of data from here to there", "On interrupt #n do this...", and those micro-ops would be in the native machine code in the VM implementation. Thus, a card's VM driver could be pretty close to optimal anyway.
However, this idea does two things that doom it:
As a result, kiss the support of the two big players you need goobye.
Well, it's certainly within the bounds of what is possible.
As for impedance: being a piezo device, they probably like lots of voltage and little current, ergo they are high impedance devices.
The problem with bass response is easy to see: imaging stretching a sheet of plastic wrap across your window frame. Turn your stereo on inside, and go outside to listen. Now, the sound will be about as good as your stereo, because the plastic wrap will be moving a fair amount back and forth, moving a lot of air.
For these speakers to do the same thing, they are going to have to be able to flex quite a bit to move enough air to make good bass. The problem is finding a piezoelectric substance that will flex that much without cracking. However, if they are using a polymer instead of a crystalline material, they may have a chance.
What if I'm not running on a system that supports Flash? Am I blocked from seeing your site? Or do I get to go straight on in, avoiding the ad?
What if I write a "Flash" plug-in that says "Yeah yeah yeah, I've show the ad, now let me in"?
Actually, I'd LOVE a subscription service that allowed me access to a fast server, no ads, and no intrusion into my personal life. Don't try to track me, just give me a way to get in (passwords e-mailed to my account that expire in a short period of time (with no spam as baggage?)) and let me go.
The only way to exploit this is if the FTP client is under the attacker's control, and passing through the firewall. This breaks down into two possible catagories:
Case 1 is the most scare from a sysad standpoint: if I had set up a world-accessible FTP server protected by a Linux firewall, the world could punch holes in my firewall.
Case 2 would be more the case of a company that chose to limit employees' access to the Internet, and the employees could use this to punch holes in the firewall. This is not as much a security risk (if you have employees who are security risks, you need to identify them and fire them.) After all, if one of your employees controls a server outside the firewall, he can always set up a proxy server on port 80 and do whatever he wants.
Still, I'm glad this sort of thing was caught and corrected. This is why peer review is important for security....
Here's the proceedure:
Don't tie all the cables on in the same place: stagger them by about a foot or two. Tape their ends as above: start at the end that will go in the wall first, and keep things smooth and snag-resistant.
Don't get too ridiculous with the number of cables you pull in this step: one or two additional cables at most, until you get a feel for what you are doing.
You ALWAYS leave a cord pulled in line, so that the next time you can just tie onto the cord and start pulling.
Also, the number of cables you can pull will depend upon how big a hole the original installers made in the joists: if they left a nice, 1 inch hole you can pull quite a bit of cable. If they just bored a hole big enough for what they were pulling, you are out of luck unless you can get access to drill larger holes.
Lastly, DON'T MIX LOW VOLTAGE LINES AND POWER LINES! Don't try to pull Ethernet, video, or RF cable through the same holes as power unless you like frying your gear, electrocuting yourself, or burning down your house and not having insurance cover it.
This is patentely wrong! The MAPS DUL does not discriminate against dial-up users, as they can send mail to whomever they want. Nor do the users of the DUL discriminate. If you want to send mail to someone, use your ISP's mailservers! That's what they are there for.
Consider: if you send email to George, and George's mailserver is down for a day because of Jethro and his backhoe, what happens:
Scenario A - you are sending the mail directly: Your client must connect every hour or so, and try to get to George's server, tying up your modem and phone line.
Scenario B - you are sending via your ISP's mailserver: You connect and send the message to your ISP's server. It then tries every hour until they get George's connection fixed, and you go about your merry way.
Which of these scenarios makes more sense?
Come on, I was on a dial-up for years, and I just tell my boxen to forward to my ISP's mailserver. It's not that hard, it saves me bandwidth, it just makes sense.
And for the argument that your ISP's mailservers suck: If your ISP cannot run its mailservers reliably, is your connection going to be any more reliable?
And for the argument that you wish to use somebody else's mailserver to receive mail: YOU CAN. Using your ISP's server to SEND your mail doesn't prevent you from retrieving your mail from some other server: that's why mail goes OUT on SMTP and comes IN on POP3/IMAP!
Lastly, for the argument that the DUL doesn't reduce SPAM: My ISP just went to using DUL filtering. My spam went from ten a day to one every couple of days.
All this info about GIS is nice, but it seems to me to be a little high-end: it's not aimed at the needs of the average user.
What I would like to see is somebody making an application like Delorme's AAA MapNGo or Microsoft's Streets and Trips available.
However, those sorts of programs are difficult to do under the Free Software model. The code isn't hard (no harder than a browser or game engine) but the program is worthless without data. And, unlike a program which you can stay in your little room and write, data requires you to have detailed maps of street locations and interconnections, locations of attractions, hotels, restaurants, and gas stations. You cannot just sit in your room and hack those out.
Now, if we could just persuade Delorme that the Free Software community is a good market...
What are you running for your packet link: 2400 or 9600? Given that packet is simplex, CD/CSMA, and requires the keyup and keydown delays for turn-arounds, I'd think TCP/IP would be unacceptably slow.
Also, how do you prevent the 5|r!p7 |1ddi3z from sending unacceptable things over the link?
If I could come up with good solutions to these problems myself, I'd be tempted to set my station back up.
73 de N0YKG
I'm a bit disappointed with Bob's answer to my question. Basically, he's taking a "If you build it, they will come" attitude to hardware support. I can think of another company that took that attitude with their computer product.
Its name was Atari.
True, many hardware vendors are supporting Linux, many more than yesterday. However, I still have my Minolta DimageII film scanner that Linux won't recognize, a Neo45 MP3 system Linux cannot talk to, and my Voodoo 3500 that Linux cannot reliably control the tuner on (although I DO get damn good framerates with XFree 4.01 DRI).
If RH were to assign a programmer to making V4L support the V3500 tuner, a programmer to making the USB->SCSI driver work reliably on the Minolta, and getting the USB->IDE interface in the Neo working, they could have that in about three man-months each. Plus, with a good framework for SCSI->USB and IDE->USB, then other people could add support. RH could act as a catylist.
(Before you say "Stop talking and start coding" - I'd love to, and I plan on it. However, I have a new house to pay for, so I have to work for a living. I cannot devote the 10 hours/day it takes to make good progress on this sort of project. Perhaps in my younger days in college... but not now.)
Sorry, but the SR-71 is a jet powered aircraft that has routinely exceeded Mach 2.1. Even F-15's have exceeded that speed.
As for Mach 5+.... no aircraft that anybody has admitted to has gone that fast.
Given Windows's propensity to spontainously combust, I can understand WHY Mr. Gates wouldn't wish to build his house around a similar theme.
The changes for SELinux have NOTHING to do with the network transport of data! They will in no way make it either easier or harder for the NSA to monitor network traffic!
SELinux is simply about making the data on your machine safe from other processes on your machine. It prevents a program from accessing any resource on the machine it is not cleared for, no matter who the process is running as.
OK, let's put on our paranoid hats <SoundFX type="crinkling aluminum foil"> and try to guess what benefit this has to the NSA: It makes it possible to use Linux in a secure environment. It gives them an OS for which they have source code (I am pretty sure they have the source for Windows(9*|NT|XP|2000) and Solaris, legally aquired), but they have the legal right to modify and distribute. This allows them to secure any government agency's computing resources in a consistant fashion. Remember, part of their job is securing OUR stuff.
Now, I'm sure that if a modification to allow all TCP traffic to be encrypted by default were to be added to normal IPv4, they might have a problem with that, since that would interfere with their normal data gathering operations. BUT, hardening Linux so a Trojan/Malicious user cannot get access to somebody else's stuff is going to make their life EASIER.
Remember, if the NSA wanted what is on your hard drive, they'd just wait till you were out, pick your locks, dd the drive, and leave.
True, in a system like this the effects of orbital mechanics would be more obvious. However, they would also be a lot harder to characterize. Consider our calendar system: months are easy, weeks are just quarter months. Now, in a moon of a gas giant, what would you use? Even if you pick the most obvious "moon", it's period as viewed from your world wouldn't be a constant.
It would be very hard to develop mathematics in this world.
If you've never read "Nightfall" by Isaac Asimov, I suggest you do so. The Good Doctor covers this item in great detail.