LiveCD? He's confined to his house, and his Windows activity is monitored. How's he going to get a copy of that LiveCD without his parole officer noticing?
Modified router? Same problem. Assuming the government has confiscated his router, he's stuck with stock. Depending on how detailed their monitoring software is, they might see him trying to mess with it.
About the only way out is to just unplug the cable, thus removing any real incentive for him to use his computer un-monitored in the first place.
I mean, I understand it's really up to the FBI how they want to do this -- after all, a convict has no rights.
I also understand that automotive analogies are lame.
However, supposing he was allowed to leave the house, would they restrict him to one brand of car?
I think what this shows, more than anything, is how stupidly incompatible software is. Java had the right idea (but a poor implementation). Software should be platform-agnostic -- perhaps enough so that the FBI could force him to run their own OS, and he'd still have all his favorite software.
Like ABC, Fox, whatever - they can do the multicast. But for the rest of the content providers, it's going to be on-demand.
Ok, if by "the rest of the content providers" you mean "YouTube", I'd agree. YouTube cannot be done with multicast. The best you can do is a caching network like Akamai.
But take anything popular enough to make a good torrent, and it's also popular enough, I think, to make good multicast.
As an example, look at how Pay-Per-View works. If I understand it, I can go onto a satellite box and purchase either a movie already being shown (and start in the middle), or I can buy the next showing and wait for it to start, or I can buy something called an "all-day pass", and then watch the movie whenever I want.
In fact, take anything that people are willing to wait that long for -- and people put up with NetFlix queues, so it can't be that bad -- and make your entire content library available that way. If nobody's currently watching a particular stream, you aren't broadcasting at all, thus wasting no bandwidth.
If on-demand is so important, and there's enough bandwidth for it, you could still use clever multicast tricks -- let someone start a second broadcast, up to a maximum number, and have them "tune in" to the first. That way, if the movie is half done when I start watching, it will download the second half while streaming the first -- after I'm done watching the first half, I can stop wasting bandwidth; the second half is right there. And it doesn't use any more bandwidth from wherever the nearest cache/proxy is to send me that second half, if I understand multicast.
Alienware caters to the hardcore gamers that aren't necessarily able to correctly install a cpu/heatsink.
This has essentially always been their business model.
So it's not surprising at all, really. Alienware's target market cannot be the technically savvy, only the technical wannabes. A technical wannabe wouldn't mind a CableCard, but they would mind being asked to plug it in themselves...
Using multicast you can send the same channel to multiple customers (IPTV) but that is broadcast, not pay-per-view.
Could be either, it just wouldn't be instantaneous.
As I understand it, pay-per-view on satellite, for instance, is the same show running all day at regular intervals. You pay for it, and have a choice of either jumping right in at wherever it's playing and watching it till the end, or waiting for the next showing to start.
This would work just as well with multicast.
You wouldn't be able to watch on-demand or fast-forward the signal. You could pause/rewind it if you had a hard drive in your set top box.
I'd say you want a hard drive there anyway. You pausing/rewinding should not result in the same data being sent to you twice.
You will also need massive hard drive caches in your POP to cache as much content as close to your subscribers as possible. Set top boxes with big drives so you can pre-load content using multicast/broadcast techniques (i.e. pre-load the new hit movie on all set boxes and make them available on the release date)
And with this, I think all those huge pipes really become unnecessary.
Really, why do most users want big pipes nowdays? Either they want web pages to load faster (in which case, really anything but dialup will work), or they want to use BitTorrent. If we had multicast that worked reasonably well, I think many BitTorrent users would switch, even if the multicast solution cost money.
FTTH is the obvious answer but that is insanley expensive
Happening in my small town in Iowa, right now.
What bothers me is, if people actually continue to use things like BitTorrent, it won't take ten users to saturate this ISP's upstream connection, once they're distributing 100meg connections to every house.
"Slammer is a nice, friendly, trustworthy piece of software I should attempt to run!" - by SanityInAnarchy
Sorry, no. The full quote was: "sure as hell doesn't mean Slammer is a nice, friendly, trustworthy piece of software I should attempt to run!"
The point is: Even if I set up my system so that it cannot possibly hurt me, running malware is still kind of pointless, which is probably why you've refused to take my test. It's also still not a good idea, which is why we don't all set up virtual machines on which to run WeatherBug, just so it can get us the weather or whatever it does.
You spent a good deal of time talking about mechanisms I could use to run this tool without putting my system at risk. You even attempted to claim that because I didn't bring them up in the first place, I must not have known about them.
Sorry, not happening until you convince me that not only is it not malware, but that it's something I'd gain some benefit from. You've presented pretty much your entire argument for that, and it's not enough, which means I'll only run it if I have too much time on my hands and really want to setup a VM for it. I was actually planning to do that this weekend, but my brother's got a LAN party happening, and you've attacked me yet again with baseless insults, including this misquote.
If this doesn't improve, I'm not even going to keep replying. For awhile, we had an interesting, almost civil conversation about filesystem design, and you even posted a comment (though unsigned) in which you stated your arguments in a simple, well-worded way, without stooping to personal attacks. But now you're back to your old tricks.
CIS Tool is not.
I only have the word of people I don't "trust" for that.
You keep trying to suggest that even if it's really all that bad, I can lock it down and run it in a sandbox. I'm just pointing out that simply because I can secure a system against malware does not mean I should go out of my way to run some.
Using those hi-res multimedia timers, I then count the ticks each routine of mine take & put it out to a file on disk OR, use a listbox recording it in memory (faster, less slow diskbound IO)....
The "worst routines" I then go after (those that take the MOST time to execute) to speed them up!
Which is my point exactly. You don't actually know which one is slower, except by actually taking measurements. Statistics.
Your technical knowledge on how OS work in terms of I/O & how it is managed, is ASTONISHINGLY LACKING, evidenced here by this exchange we had:
Then reply to me there. You're the one lacking.
I lack certain specific knowledge about Windows, but I am not the one who thinks it's a good idea to put a pagefile in RAM!
That's as logical as trying to create a perpetual motion machine! Which is to say, it isn't.
Now, stop changing the subject. You were specifically avoiding a question by simply saying "lol, you're wrong" or something to that effect. And rather than address it, you'd now like to bring in another discussion.
The stats I cite are valid... they are the summation of ALL vulnerabilities present in *NIX's & their apps VS. those in Windows & its apps...
No, they are not.
If they were, don't you think you'd see FAR more vulnerabilities in Windows, given how many more apps exist for it?
Again: How is the data I listed invalid?
You mention more than a few ancedotes as "statistics", including the recent compromise of the Ubuntu servers.
I do CIS TOOL posts for 1 reason here:
That for all the:
"(Insert *NIX variant here) is more secure or securable than Windows"
And yet, you were willing to carry on a conversation for this long, trying to convince me to run the test for mysel
Here's the problem with that: A publicly accessible website isn't good enough, because people can now buy votes outright. They simply wait for you to come out, visit the public website, and see who you voted for. They then pay you what you agreed upon ahead of time.
If no one, even you, can prove how you voted, then votes can't be bought from individuals.
It's also not good enough to simply see your own vote echoed back. You have to be able to see every vote up there, so that you can do a "recount" yourself -- including sanity checks like how many people voted. The more transparent it is (without actually showing who voted for whom), the fewer ways there are of fixing an election.
Probably the closest we can get is to make it possible, even easy, for people to verify to themselves that their vote was counted, and it was counted for who they said it was for, but not make it so easy to prove this to others, except by looking at a paper trail. That way, if a lot of people start to realize that their vote wasn't counted, they can demand a recount from the paper trail.
As an example: Allow the user to enter some passphrase into the machine, and then later into the website -- something they can memorize. But have an incorrect passphrase still produce a valid result. That way, you can "prove" to someone that your vote was counted for one candidate, and "prove" to yourself that it was counted for another. But it makes it difficult to "prove" that there's a miscount, except by a lot of people forming an angry mob because their votes weren't counted.
the form itself was served with https, when whats important is that the form data is going to be submitted via https.
Because if the form was served with https, and you trust the site at all, then they'll have you submit the data with https.
Anyway, what really bothers me is that if you serve a login page via http, you're now vulnerable to a man-in-the-middle attack. It's now possible for someone to redirect live.microsoft.com (or is it live.msn.com?) to their own page, which would look exactly the same, except that it would submit the data to the attacker.
Not as easily, I think. And you're right, the availability of the software is pretty slim.
If I was passing around a document I wanted people to be able to edit, I wouldn't use PDF. I'd use PDF for things I really don't want anyone to be able to edit at all.
Ugh, I hope that is all accurate above... I need coffee this a.m.!
I know the feeling... I'll try to keep that in mind as I read through this. Couple mistakes, not many, I think.
The REGISTRY "HIVES" (flat file tables linked to one another, not like a typical relational database though) not called SYSTEM.REG/USER.REG by the way... the hives are called:
Ok, so it looks like I was right here. The registry hives are files. Doesn't matter much to me what they're called, there are still a very small number of them, and they are a layer separate than the filesystem.
One goal I have is to improve the filesystem to where you don't need anything like a Registry.
1.) Application (performing a read operation NtReadFile)
NtReadFile is what I'm interested in here, and what I meant when I said "API".
It doesn't matter to the application developer what actually happens, or how it gets loaded into their app -- it's all about semantics. It's about: I have NtReadFile, maybe NtWriteFile, NtMoveFile, etc.
Is there something like: NtCopyFile? If so, the OS could implement copy-on-write files without having to alter applications. By that I mean, when the user right-click-drags a file to somewhere else, and says "copy here", it doesn't make an actual copy, only a copy-on-write link (something like a hardlink).
Unix-like systems can't do this without rewriting applications. We have read, write, rename, unlink, and so on. But we don't have a "copy" system call. If one were created, most apps would not already be using it. So if a filesystem were created which supported this kind of transparent copy-on-write-ness, most apps would not be able to take advantage of it -- including the Unix "cp" command -- until they were updated.
AMD is releasing kits for multiprocessor systems, for JUST THAT VERY THING (the ability to meter cache hits/misses
"Page cache" in Linux is more like disk cache. It has nothing to do with the CPU cache, which is probably what AMD's kit is about.
On deferred/lazy writes? Well, so does other diskbound I/O, albeit, via the cache manager subsystem...
Your example was about reads.
But the problem isn't whether an app can suggest that a write be deferred/lazy, but whether it can do so safely (transactions). Right now, databases and such, like MySQL and PostgreSQL, can be built on top of a Unix filesystem, but essentially, they have to duplicate a lot of the effort of the filesystem in their own code. They have to implement their own transactions, sync them properly, do journaling, and so on.
But I want this in filesystem operations. Take, for example, updating a simple text config file. Let's say it's/etc/passwd, because everyone knows what that is. The proper way to do this, to prevent/etc/passwd from ever being in an inconsistent state, is to write to a new file first, something like "/etc/passwd.new", and then rename the new file on top of/etc/passwd. The rename is an atomic operation on journaled filesystems.
The problem is, do the writes to passwd.new hit disk before or after the rename of passwd.new to passwd? Ideally, we want the filesystem to be able to reorder writes intelligently, but in this case, we want to be sure passwd.new is complete and consistent first, so we fsync it -- we tell the FS to write it to disk, and let us know when that's done -- and then we rename it.
That fsync should not be necessary.
So, package managers do this kind of thing all the time, and they do it enough that all those fsync calls could be a strain on performance. But so could having the filesystem forced into ordered mode. And really, the user doesn't care if one particular file is updated and synced to disk RIGHT NOW. What we want is to be sure that nothing's left completely corrupt and unusable if
Yet again, I reject that comparing the very most recent version is sufficient statistical evidence. As I understand it, SQL Server 2005 is two years old, and SQL Server 2000 was three years old when it was hit with the SQL Slammer worm.
So, come back in five or ten years, and we can compare SQL Server 2005 -- maybe it'll be hit with a massive worm next year. Otherwise, either compare broader sets of versions, or older ones.
In any case, I would like to point out that I think statistics are tricky to do right, and neither of us has provided a completely undisputable statistical comparison. Except maybe mine, pointing out that for most of its history, Linux has not been attacked, while Windows has, badly.
My guess is that someone who is clueful enough to use either ODF or OOXML is clueful enough to at least understand, say, Word's "Save as HTML" feature, or use an actual HTML solution from the beginning.
That would be why.doc is still the overwhelming majority.
However, there are times when it makes sense. For example, manuals which were always meant to be printed and physically included with a piece of hardware often go on the Web as PDF, because that's the format in which they're sent to the printer, so putting them online takes no work -- compared to redoing it as HTML. (I haven't found a reliable pdf->html converter yet.)
And there are other examples, even beyond distributing content. You could say "Take a look at my document here, notice how nicely OpenOffice handles this particular feature..." Of course, you could post screenshots, but you should really do both, unless the documents are partly confidential.
With DRM, you know when you've successfully removed it, because you can play it with a player they didn't intend. Once it works in VLC, you're done.
With watermarking, you never know if you've been entirely successful removing everything (without making the sound too much worse), so it seems to me a lot less likely that people will want to release songs onto P2P networks in the first place. Of course, some idiots won't know this, and we'll have copies of their music all over the Intarwebs, and the RIAA will come down on them like a ton of bricks -- finally, a solid "example" case they can win.
In my case, I much prefer watermarking to DRM. If DRM is the primary means of copy protection, that means I will generally refuse to buy it if it's multimedia (as in, not a game) because it will limit what platforms I can play it on, and what mediums I can store it on. If Watermarking were to replace DRM, it would be at least as effective (which isn't saying much; DRM is easy to crack), and maybe even more effective. But as a customer, I'd much rather buy the watermarked file, because I know it'll work.
DRM is punishing legitimate customers because they might be customers, while pirates get a better experience.
Watermarking is punishing unskilled pirates. It might let the skilled pirates keep doing what they're doing, but at least it's no longer punishing the legitimate users and driving them to piracy.
The blocking that they seem to be advocating that others use is pretty standard "HTTP_USER_AGENT" querying using a PHP script
Which means he's flatly retarded.
He's not testing for Adblock, he's testing for Firefox, because Firefox has extensions that allow this. So he's now screwed himself over -- I have Konqueror, and I have a large number of user-agent strings I can switch to easily, for a single site. I'll visit him on Konqueror, make it look like IE, and still block his ads -- not to mention Slashdot him to hell.
Yet you didn't even want to look at statistics until you found some ancedotes you thought might count as statistics. So much for your statistics classes.
Let me put it this way: When you want to optimize a program for speed, do you immediately jump to things like unrolling loops, or hell, maybe -Os, whatever you feel is the best way to squeeze more speed out of it? Do you do these things, and just assume your computer is faster?
Or do you actually go benchmark it? No, not with some tool that estimates how fast it should theoretically run -- what your CIS tool appears to do -- but an actual profiler, which measures and gives you a statistical analysis of where your program is spending the most time?
How's that? EVEN IF it could send out data, without my consent? It'd have to blow past layered security of IPSec policies, software firewall (ZA)...
I just suggested it was malware, and now you're saying it's not because it won't affect you.
Yeah, SQL Slammer won't hit my Postgres server, but that sure as hell doesn't mean Slammer is a nice, friendly, trustworthy piece of software I should attempt to run!
worst comes to worst (not that I mind it contributing to a database of security scores + techniques mind you)?
I might not mind either. I mind that they didn't ask.
It says something about their character and professionalism that means I'm much less likely to trust any result from their program, or to want to do anything else with their program other than throw it away.
Ask yourself this: How likely would you be to hire the author of BonziBuddy or Gator to help you write some antivirus or antispyware?
If I WERE worried about that? I'd either disable my network connection, or unplug my router... no NET access, period...
Yes, I intend to. Or at least a softer version of that -- I'll run it in a VPN with net access disabled, maybe even a serial console only.
Yes, & that is PRETTY MUCH what you stated about it as well, per your quote, in another thread in our discussion here... but, how many wares have "disclaimers" in them like that, OR their documentation? MOST today, DO!
In that case, if you're being honest, you should put a similar disclaimer in your own quotes.
And by the way, the tone of it was, again, one of "fair and unbiased reporting", which means that even if they thought it was the worst software imaginable, they could have given a pretty much identical report.
SANS & COMPUTERWORLD sure as hell didn't say it was malware
Then please counter me where I say they did, with a quote, instead of bringing it up without context here, with no better defense than "lol".
Is "lol" your only defense? Pathetic.
(the things needed are NOT hard to do, & DO implement layered security).
Oh? You mean you've done them?
In that case, you don't need me, you can just run it on the Linux box you've built and secured!
for tracing its files on disk (tools for this from SysInternals help here, RegMon, FileMon, DiskMon, Process Monitor & are FREE + very VERY good)...
And none for Linux.
There are ways I can watch it, things like strace. However, that still doesn't tell me what I want to know -- whether a particular write was a good write, and well intended, or a bad write. The best I can do is run them under SELinux, or virtual machines (what I intend to do), such that there's no way I can think of that anything else can affect the test, or that the test can affect anything else.
I realize it looks like I'm changing my position. I'm not. My position is not necessarily that I'm worried about the software damaging my systems -- from the beginning, anyone kno
I know 1 statistic that might disturb you though - Windows dominance in the world of PC's, from single user home rigs, to home LANs, up thru departmental servers, right up into the datacenter for mission critical servers
Sorry, dominance in the datacenter is a very recent thing, and actually not a very solid one. They have maybe 50% marketshare, last I looked, up from 25%.
"Having some big important name depend on us" is not the same thing as "dominating." It's an ancedote, and I've got a few for you -- Dreamworks and ILM have moved to Linux renderfarms, even many of them to Linux workstations. Lord of the Rings was rendered on Linux, and the Halo movie is likely to be as well.
But dominance has nothing to do with security -- in fact, dominance lessens your effective security on Windows, because it gains none of the security benefits of a popular open project, and all of the detriment of being such a huge target.
To me, effective security is more important than theoretical security. Linux is a reasonably secure platform. I cannot say whether it's fundamentally more or less secure than NT. However, it's close enough that being a smaller target makes it more secure. I believe it would continue to be more secure even if it were a larger target, because it would also get a larger team of developers for free, and because I believe open projects have much more motivation to be secure than closed ones.
Windows Server 2003 + SQLServer 2005 (which has NO VULNERABILITIES IN IT, in this version, thru its entire history)
Yeah, and while we're at it, I've just written a piece of software which has no vulnerabilities in it.
What's my secret?
I just wrote it, duh.
SQL Server 2005 is, if I'm not mistaken, the most recent SQL Server product. If you really want a fair comparison, look at the longer history -- SQL Server 2003 or so, I think, was hit by SQL Slammer. I don't know of any worms named after MySQL or PostgreSQL -- ANY version of them.
So yes, if you're going to deliberately skew your sample sets in order to prove your point, you're right -- statistics get us nowhere. I'm not trying to skew anything, I'm trying the best I can to find fair comparisons that don't require me to do a lot of independent number crunching on my own.
Want stats though? OK, a super-current one (Lol!):
That's not a stat, it's just another ancedote.
Keep in mind, these are not the servers actually owned by Ubuntu, these are donated ones.
But I've got an ancedote of my own: I distinctly remember at least one instance in which the Windows Update servers were not only cracked, but were used to distribute malware as an automatic update. So this buys you nothing.
"There were 5198 reported vulnerabilities: 812 Windows operating system vulnerabilities; 2328 Unix/Linux operating vulnerabilities; and 2058 Multiple operating system vulnerabilities."
I really hate it when you copy and paste an argument I've already responded to, especially when you don't have anything new to say. Apparently, you either agree with my response (and are embarrassed enough to want to hide it), or you have been skimming my posts again.
Simply put, that is not an apples to apples comparison, and is, in fact, about as far as you can get from an apples to apples comparison.
Registry, iirc, it's also governed by the kernel components subsystems of IO Manager (overall governor component iirc), then Cache Manager...
And so on.
I'm not counting Registry as part of what I want, because as far as I can see, the Registry sits on top of the Filesystem itself -- in the *.reg files. (System.reg, User.reg, etc.) To me, the Registry is just another database sitting on top of the filesystem, an alternate API to the filesystem API itself.
The other things you bring up are valid, but they are not APIs, they are part of a particular filesystem implementation, or of the generic Windows filesystem facilities. When writing a program, it helps to know about things like page cache, and yes, I would like to see filesystems/OSes implement this better. But the actual filesystem API itself -- the open/read/write/sync library calls -- is too limiting/low-level to let the OS/filesystem do the kind of optimizations I'd like, without risking corruption.
once a minute writes lazy deferred
See, the Registry may just have an API that lets it do that... But in this case, that behavior isn't always what you want.
On a desktop or server, where the disk is always spinning and you want max performance, you just defer the write till there's not many reads happening, then write immediately, everything you can, till someone needs to read. Increases disk wear, but it means you never have a situation where you have to flush madly due to lack of RAM, and if you're careful, it won't affect read performance much, if at all. It certainly won't affect write performance, for asynchronous stuff, and anything synchronous really should be written to permanent storage.
However, take a Flash laptop. You're probably not likely to crash, and you want to save power. If your main storage is Flash, you can probably afford to sacrifice a little performance for media longevity and batter life. So, here, you delay as long as you possibly can, maybe even ignore syncs (bad idea, though), and write everything as late as possible, probably as little as you can, with proper wear-leveling -- by then you'll have a good idea of how you want to allocate it so as to overwrite the fewest number of sectors.
Or take a laptop with a magnetic disk. Delay everything as long as possible, but as soon as there's a disk read -- as soon as the drive spins up for any reason -- you write everything pending. Linux Laptop Mode does this, but I don't think it knows enough about the filesystem internals to be smart about it -- for instance, the case where a temporary file is created and destroyed before it hits disk, or a file is modified so rapidly that there's no point trying to write it to disk unless you have to.
What you want is a filesystem API that will support all of these behaviors, without corrupting application data, and implement them in the same place, so you don't have, for example, Registry writes being lazy and NTFS writes being immediate or even synchronous.
Copy On Write functionality for shared data also helps here vs. shared data & corrupting it...
Is this possible from a user perspective? For example, can a non-admin create a complete or partial copy-on-write copy of a file? Or splice multiple files together that way?
If so, that's a point against Unix, which has no "copy" system call at all -- cp is implemented with reads and writes, so the actual decision of how to copy is made within the application itself -- and copy-on-write must then be implemented by the application, and not the filesystem -- meaning applications have to cooperate if all want to see the copy-on-write effect.
I.E.-> Each app calling the data has a LOCAL COPY of a file's data, to itself, & the writes are queued by the above, in order as best it can be done.
Oh... looks like you were talking more about cache and read/write tricks than... well... wh
Offtopic, and I know what you mean, but if you know C++, it will be even easier to learn what you're missing of C -- which is basically tips and tricks with how it's used.
But I'd rather fix Wine than ReactOS... Oh well, good luck to both of them.
If Linux was anywhere near as good as Windows it would be far more popular than it is today.
That depends what you mean by "near as good". I'd say, it has to be hugely better than Windows -- at least as much as OS X is better than OS 9.
When the best applications aren't available on Linux, that's not "almost as good". When you have to carefully pick and choose your hardware because only a few have Linux drivers, that's not "almost as good".
No, but that's not Linux's fault either. Apps won't be ported, drivers won't be supplied by manufacturers, until Linux is more popular. Linux won't get more popular until there are apps and drivers.
Chickens and eggs. It's actually impossible for any new OS to enter the market and beat Microsoft right now, because Windows has more stuff because everyone uses Windows because Windows has more stuff.
And the actions of millions of people all over the world shows that they feel the same.
How many millions of people eat white bread? I was raised on wheat, and I think it tastes better.
How many of the people born and raised on white bread have actually tasted whole wheat bread?
The market share doesn't prove anything other than that more people use Windows. Many of these people may simply not be aware of Linux.
It was something like 50 centavos an hour -- that's half a Sole. The conversion rate is something like three Soles to the dollar.
Pretty much every computer there was some flavor of XP, many on crappy old computers, and always insanely cheap like that. Either it's MUCH cheaper to get Peruvian Windows, or there's a lot of piracy going on. Wouldn't be surprised by either.
Slashdot Mirror
LiveCD? He's confined to his house, and his Windows activity is monitored. How's he going to get a copy of that LiveCD without his parole officer noticing?
Modified router? Same problem. Assuming the government has confiscated his router, he's stuck with stock. Depending on how detailed their monitoring software is, they might see him trying to mess with it.
About the only way out is to just unplug the cable, thus removing any real incentive for him to use his computer un-monitored in the first place.
I mean, I understand it's really up to the FBI how they want to do this -- after all, a convict has no rights.
I also understand that automotive analogies are lame.
However, supposing he was allowed to leave the house, would they restrict him to one brand of car?
I think what this shows, more than anything, is how stupidly incompatible software is. Java had the right idea (but a poor implementation). Software should be platform-agnostic -- perhaps enough so that the FBI could force him to run their own OS, and he'd still have all his favorite software.
Ok, if by "the rest of the content providers" you mean "YouTube", I'd agree. YouTube cannot be done with multicast. The best you can do is a caching network like Akamai.
But take anything popular enough to make a good torrent, and it's also popular enough, I think, to make good multicast.
As an example, look at how Pay-Per-View works. If I understand it, I can go onto a satellite box and purchase either a movie already being shown (and start in the middle), or I can buy the next showing and wait for it to start, or I can buy something called an "all-day pass", and then watch the movie whenever I want.
In fact, take anything that people are willing to wait that long for -- and people put up with NetFlix queues, so it can't be that bad -- and make your entire content library available that way. If nobody's currently watching a particular stream, you aren't broadcasting at all, thus wasting no bandwidth.
If on-demand is so important, and there's enough bandwidth for it, you could still use clever multicast tricks -- let someone start a second broadcast, up to a maximum number, and have them "tune in" to the first. That way, if the movie is half done when I start watching, it will download the second half while streaming the first -- after I'm done watching the first half, I can stop wasting bandwidth; the second half is right there. And it doesn't use any more bandwidth from wherever the nearest cache/proxy is to send me that second half, if I understand multicast.
This has essentially always been their business model.
So it's not surprising at all, really. Alienware's target market cannot be the technically savvy, only the technical wannabes. A technical wannabe wouldn't mind a CableCard, but they would mind being asked to plug it in themselves...
Could be either, it just wouldn't be instantaneous.
As I understand it, pay-per-view on satellite, for instance, is the same show running all day at regular intervals. You pay for it, and have a choice of either jumping right in at wherever it's playing and watching it till the end, or waiting for the next showing to start.
This would work just as well with multicast.
I'd say you want a hard drive there anyway. You pausing/rewinding should not result in the same data being sent to you twice.
And with this, I think all those huge pipes really become unnecessary.
Really, why do most users want big pipes nowdays? Either they want web pages to load faster (in which case, really anything but dialup will work), or they want to use BitTorrent. If we had multicast that worked reasonably well, I think many BitTorrent users would switch, even if the multicast solution cost money.
Happening in my small town in Iowa, right now.
What bothers me is, if people actually continue to use things like BitTorrent, it won't take ten users to saturate this ISP's upstream connection, once they're distributing 100meg connections to every house.
Sorry, no. The full quote was: "sure as hell doesn't mean Slammer is a nice, friendly, trustworthy piece of software I should attempt to run!"
The point is: Even if I set up my system so that it cannot possibly hurt me, running malware is still kind of pointless, which is probably why you've refused to take my test. It's also still not a good idea, which is why we don't all set up virtual machines on which to run WeatherBug, just so it can get us the weather or whatever it does.
You spent a good deal of time talking about mechanisms I could use to run this tool without putting my system at risk. You even attempted to claim that because I didn't bring them up in the first place, I must not have known about them.
Sorry, not happening until you convince me that not only is it not malware, but that it's something I'd gain some benefit from. You've presented pretty much your entire argument for that, and it's not enough, which means I'll only run it if I have too much time on my hands and really want to setup a VM for it. I was actually planning to do that this weekend, but my brother's got a LAN party happening, and you've attacked me yet again with baseless insults, including this misquote.
If this doesn't improve, I'm not even going to keep replying. For awhile, we had an interesting, almost civil conversation about filesystem design, and you even posted a comment (though unsigned) in which you stated your arguments in a simple, well-worded way, without stooping to personal attacks. But now you're back to your old tricks.
I only have the word of people I don't "trust" for that.
You keep trying to suggest that even if it's really all that bad, I can lock it down and run it in a sandbox. I'm just pointing out that simply because I can secure a system against malware does not mean I should go out of my way to run some.
Which is my point exactly. You don't actually know which one is slower, except by actually taking measurements. Statistics.
Then reply to me there. You're the one lacking.
I lack certain specific knowledge about Windows, but I am not the one who thinks it's a good idea to put a pagefile in RAM!
That's as logical as trying to create a perpetual motion machine! Which is to say, it isn't.
Now, stop changing the subject. You were specifically avoiding a question by simply saying "lol, you're wrong" or something to that effect. And rather than address it, you'd now like to bring in another discussion.
No, they are not.
If they were, don't you think you'd see FAR more vulnerabilities in Windows, given how many more apps exist for it?
You mention more than a few ancedotes as "statistics", including the recent compromise of the Ubuntu servers.
And yet, you were willing to carry on a conversation for this long, trying to convince me to run the test for mysel
My name... is Premere Electronic Solutions!
Just doesn't have the same ring to it.
Here's the problem with that: A publicly accessible website isn't good enough, because people can now buy votes outright. They simply wait for you to come out, visit the public website, and see who you voted for. They then pay you what you agreed upon ahead of time.
If no one, even you, can prove how you voted, then votes can't be bought from individuals.
It's also not good enough to simply see your own vote echoed back. You have to be able to see every vote up there, so that you can do a "recount" yourself -- including sanity checks like how many people voted. The more transparent it is (without actually showing who voted for whom), the fewer ways there are of fixing an election.
Probably the closest we can get is to make it possible, even easy, for people to verify to themselves that their vote was counted, and it was counted for who they said it was for, but not make it so easy to prove this to others, except by looking at a paper trail. That way, if a lot of people start to realize that their vote wasn't counted, they can demand a recount from the paper trail.
As an example: Allow the user to enter some passphrase into the machine, and then later into the website -- something they can memorize. But have an incorrect passphrase still produce a valid result. That way, you can "prove" to someone that your vote was counted for one candidate, and "prove" to yourself that it was counted for another. But it makes it difficult to "prove" that there's a miscount, except by a lot of people forming an angry mob because their votes weren't counted.
Because if the form was served with https, and you trust the site at all, then they'll have you submit the data with https.
Anyway, what really bothers me is that if you serve a login page via http, you're now vulnerable to a man-in-the-middle attack. It's now possible for someone to redirect live.microsoft.com (or is it live.msn.com?) to their own page, which would look exactly the same, except that it would submit the data to the attacker.
Yeah, that's why no one uses Wikis. Oh wait...
Not as easily, I think. And you're right, the availability of the software is pretty slim.
If I was passing around a document I wanted people to be able to edit, I wouldn't use PDF. I'd use PDF for things I really don't want anyone to be able to edit at all.
I know the feeling... I'll try to keep that in mind as I read through this. Couple mistakes, not many, I think.
Ok, so it looks like I was right here. The registry hives are files. Doesn't matter much to me what they're called, there are still a very small number of them, and they are a layer separate than the filesystem.
One goal I have is to improve the filesystem to where you don't need anything like a Registry.
NtReadFile is what I'm interested in here, and what I meant when I said "API".
It doesn't matter to the application developer what actually happens, or how it gets loaded into their app -- it's all about semantics. It's about: I have NtReadFile, maybe NtWriteFile, NtMoveFile, etc.
Is there something like: NtCopyFile? If so, the OS could implement copy-on-write files without having to alter applications. By that I mean, when the user right-click-drags a file to somewhere else, and says "copy here", it doesn't make an actual copy, only a copy-on-write link (something like a hardlink).
Unix-like systems can't do this without rewriting applications. We have read, write, rename, unlink, and so on. But we don't have a "copy" system call. If one were created, most apps would not already be using it. So if a filesystem were created which supported this kind of transparent copy-on-write-ness, most apps would not be able to take advantage of it -- including the Unix "cp" command -- until they were updated.
"Page cache" in Linux is more like disk cache. It has nothing to do with the CPU cache, which is probably what AMD's kit is about.
Your example was about reads.
But the problem isn't whether an app can suggest that a write be deferred/lazy, but whether it can do so safely (transactions). Right now, databases and such, like MySQL and PostgreSQL, can be built on top of a Unix filesystem, but essentially, they have to duplicate a lot of the effort of the filesystem in their own code. They have to implement their own transactions, sync them properly, do journaling, and so on.
But I want this in filesystem operations. Take, for example, updating a simple text config file. Let's say it's /etc/passwd, because everyone knows what that is. The proper way to do this, to prevent /etc/passwd from ever being in an inconsistent state, is to write to a new file first, something like "/etc/passwd.new", and then rename the new file on top of /etc/passwd. The rename is an atomic operation on journaled filesystems.
The problem is, do the writes to passwd.new hit disk before or after the rename of passwd.new to passwd? Ideally, we want the filesystem to be able to reorder writes intelligently, but in this case, we want to be sure passwd.new is complete and consistent first, so we fsync it -- we tell the FS to write it to disk, and let us know when that's done -- and then we rename it.
That fsync should not be necessary.
So, package managers do this kind of thing all the time, and they do it enough that all those fsync calls could be a strain on performance. But so could having the filesystem forced into ordered mode. And really, the user doesn't care if one particular file is updated and synced to disk RIGHT NOW. What we want is to be sure that nothing's left completely corrupt and unusable if
Yet again, I reject that comparing the very most recent version is sufficient statistical evidence. As I understand it, SQL Server 2005 is two years old, and SQL Server 2000 was three years old when it was hit with the SQL Slammer worm.
So, come back in five or ten years, and we can compare SQL Server 2005 -- maybe it'll be hit with a massive worm next year. Otherwise, either compare broader sets of versions, or older ones.
In any case, I would like to point out that I think statistics are tricky to do right, and neither of us has provided a completely undisputable statistical comparison. Except maybe mine, pointing out that for most of its history, Linux has not been attacked, while Windows has, badly.
My guess is that someone who is clueful enough to use either ODF or OOXML is clueful enough to at least understand, say, Word's "Save as HTML" feature, or use an actual HTML solution from the beginning.
.doc is still the overwhelming majority.
That would be why
However, there are times when it makes sense. For example, manuals which were always meant to be printed and physically included with a piece of hardware often go on the Web as PDF, because that's the format in which they're sent to the printer, so putting them online takes no work -- compared to redoing it as HTML. (I haven't found a reliable pdf->html converter yet.)
And there are other examples, even beyond distributing content. You could say "Take a look at my document here, notice how nicely OpenOffice handles this particular feature..." Of course, you could post screenshots, but you should really do both, unless the documents are partly confidential.
Nor is there a F/OSS category, or a GNU category, as far as I remember when I last tried to submit a story.
Seems to me, "Linux" is as good as anything to describe this.
With DRM, you know when you've successfully removed it, because you can play it with a player they didn't intend. Once it works in VLC, you're done.
With watermarking, you never know if you've been entirely successful removing everything (without making the sound too much worse), so it seems to me a lot less likely that people will want to release songs onto P2P networks in the first place. Of course, some idiots won't know this, and we'll have copies of their music all over the Intarwebs, and the RIAA will come down on them like a ton of bricks -- finally, a solid "example" case they can win.
In my case, I much prefer watermarking to DRM. If DRM is the primary means of copy protection, that means I will generally refuse to buy it if it's multimedia (as in, not a game) because it will limit what platforms I can play it on, and what mediums I can store it on. If Watermarking were to replace DRM, it would be at least as effective (which isn't saying much; DRM is easy to crack), and maybe even more effective. But as a customer, I'd much rather buy the watermarked file, because I know it'll work.
DRM is punishing legitimate customers because they might be customers, while pirates get a better experience.
Watermarking is punishing unskilled pirates. It might let the skilled pirates keep doing what they're doing, but at least it's no longer punishing the legitimate users and driving them to piracy.
Which means he's flatly retarded.
He's not testing for Adblock, he's testing for Firefox, because Firefox has extensions that allow this. So he's now screwed himself over -- I have Konqueror, and I have a large number of user-agent strings I can switch to easily, for a single site. I'll visit him on Konqueror, make it look like IE, and still block his ads -- not to mention Slashdot him to hell.
He's specifically asking Firefox users to switch to IE in some form, so that they stop blocking his ads.
Well, fine. So they switch to IE and install AdMuncher.
Or, hell, switch the user agent! I'm still waiting for his "how to block Firefox" page to load, but I bet that's all he does.
Yet you didn't even want to look at statistics until you found some ancedotes you thought might count as statistics. So much for your statistics classes.
Let me put it this way: When you want to optimize a program for speed, do you immediately jump to things like unrolling loops, or hell, maybe -Os, whatever you feel is the best way to squeeze more speed out of it? Do you do these things, and just assume your computer is faster?
Or do you actually go benchmark it? No, not with some tool that estimates how fast it should theoretically run -- what your CIS tool appears to do -- but an actual profiler, which measures and gives you a statistical analysis of where your program is spending the most time?
I just suggested it was malware, and now you're saying it's not because it won't affect you.
Yeah, SQL Slammer won't hit my Postgres server, but that sure as hell doesn't mean Slammer is a nice, friendly, trustworthy piece of software I should attempt to run!
I might not mind either. I mind that they didn't ask.
It says something about their character and professionalism that means I'm much less likely to trust any result from their program, or to want to do anything else with their program other than throw it away.
Ask yourself this: How likely would you be to hire the author of BonziBuddy or Gator to help you write some antivirus or antispyware?
Yes, I intend to. Or at least a softer version of that -- I'll run it in a VPN with net access disabled, maybe even a serial console only.
In that case, if you're being honest, you should put a similar disclaimer in your own quotes.
And by the way, the tone of it was, again, one of "fair and unbiased reporting", which means that even if they thought it was the worst software imaginable, they could have given a pretty much identical report.
Then please counter me where I say they did, with a quote, instead of bringing it up without context here, with no better defense than "lol".
Is "lol" your only defense? Pathetic.
Oh? You mean you've done them?
In that case, you don't need me, you can just run it on the Linux box you've built and secured!
And none for Linux.
There are ways I can watch it, things like strace. However, that still doesn't tell me what I want to know -- whether a particular write was a good write, and well intended, or a bad write. The best I can do is run them under SELinux, or virtual machines (what I intend to do), such that there's no way I can think of that anything else can affect the test, or that the test can affect anything else.
I realize it looks like I'm changing my position. I'm not. My position is not necessarily that I'm worried about the software damaging my systems -- from the beginning, anyone kno
Weird. I've had just the opposite experience on one machine, actually. Only got it working on InfraRecorder.
Sorry, dominance in the datacenter is a very recent thing, and actually not a very solid one. They have maybe 50% marketshare, last I looked, up from 25%.
"Having some big important name depend on us" is not the same thing as "dominating." It's an ancedote, and I've got a few for you -- Dreamworks and ILM have moved to Linux renderfarms, even many of them to Linux workstations. Lord of the Rings was rendered on Linux, and the Halo movie is likely to be as well.
But dominance has nothing to do with security -- in fact, dominance lessens your effective security on Windows, because it gains none of the security benefits of a popular open project, and all of the detriment of being such a huge target.
To me, effective security is more important than theoretical security. Linux is a reasonably secure platform. I cannot say whether it's fundamentally more or less secure than NT. However, it's close enough that being a smaller target makes it more secure. I believe it would continue to be more secure even if it were a larger target, because it would also get a larger team of developers for free, and because I believe open projects have much more motivation to be secure than closed ones.
Yeah, and while we're at it, I've just written a piece of software which has no vulnerabilities in it.
What's my secret?
I just wrote it, duh.
SQL Server 2005 is, if I'm not mistaken, the most recent SQL Server product. If you really want a fair comparison, look at the longer history -- SQL Server 2003 or so, I think, was hit by SQL Slammer. I don't know of any worms named after MySQL or PostgreSQL -- ANY version of them.
So yes, if you're going to deliberately skew your sample sets in order to prove your point, you're right -- statistics get us nowhere. I'm not trying to skew anything, I'm trying the best I can to find fair comparisons that don't require me to do a lot of independent number crunching on my own.
That's not a stat, it's just another ancedote.
Keep in mind, these are not the servers actually owned by Ubuntu, these are donated ones.
But I've got an ancedote of my own: I distinctly remember at least one instance in which the Windows Update servers were not only cracked, but were used to distribute malware as an automatic update. So this buys you nothing.
I really hate it when you copy and paste an argument I've already responded to, especially when you don't have anything new to say. Apparently, you either agree with my response (and are embarrassed enough to want to hide it), or you have been skimming my posts again.
Simply put, that is not an apples to apples comparison, and is, in fact, about as far as you can get from an apples to apples comparison.
I only remember one episode in which the entire bridge could see it, and Insurrection, in which only the audience could see it.
But I believe the idea was the same, and anyway, Insurrection gave him entirely artificial eyes instead of a visor.
And so on.
I'm not counting Registry as part of what I want, because as far as I can see, the Registry sits on top of the Filesystem itself -- in the *.reg files. (System.reg, User.reg, etc.) To me, the Registry is just another database sitting on top of the filesystem, an alternate API to the filesystem API itself.
The other things you bring up are valid, but they are not APIs, they are part of a particular filesystem implementation, or of the generic Windows filesystem facilities. When writing a program, it helps to know about things like page cache, and yes, I would like to see filesystems/OSes implement this better. But the actual filesystem API itself -- the open/read/write/sync library calls -- is too limiting/low-level to let the OS/filesystem do the kind of optimizations I'd like, without risking corruption.
See, the Registry may just have an API that lets it do that... But in this case, that behavior isn't always what you want.
On a desktop or server, where the disk is always spinning and you want max performance, you just defer the write till there's not many reads happening, then write immediately, everything you can, till someone needs to read. Increases disk wear, but it means you never have a situation where you have to flush madly due to lack of RAM, and if you're careful, it won't affect read performance much, if at all. It certainly won't affect write performance, for asynchronous stuff, and anything synchronous really should be written to permanent storage.
However, take a Flash laptop. You're probably not likely to crash, and you want to save power. If your main storage is Flash, you can probably afford to sacrifice a little performance for media longevity and batter life. So, here, you delay as long as you possibly can, maybe even ignore syncs (bad idea, though), and write everything as late as possible, probably as little as you can, with proper wear-leveling -- by then you'll have a good idea of how you want to allocate it so as to overwrite the fewest number of sectors.
Or take a laptop with a magnetic disk. Delay everything as long as possible, but as soon as there's a disk read -- as soon as the drive spins up for any reason -- you write everything pending. Linux Laptop Mode does this, but I don't think it knows enough about the filesystem internals to be smart about it -- for instance, the case where a temporary file is created and destroyed before it hits disk, or a file is modified so rapidly that there's no point trying to write it to disk unless you have to.
What you want is a filesystem API that will support all of these behaviors, without corrupting application data, and implement them in the same place, so you don't have, for example, Registry writes being lazy and NTFS writes being immediate or even synchronous.
Is this possible from a user perspective? For example, can a non-admin create a complete or partial copy-on-write copy of a file? Or splice multiple files together that way?
If so, that's a point against Unix, which has no "copy" system call at all -- cp is implemented with reads and writes, so the actual decision of how to copy is made within the application itself -- and copy-on-write must then be implemented by the application, and not the filesystem -- meaning applications have to cooperate if all want to see the copy-on-write effect.
Oh... looks like you were talking more about cache and read/write tricks than... well... wh
Offtopic, and I know what you mean, but if you know C++, it will be even easier to learn what you're missing of C -- which is basically tips and tricks with how it's used.
But I'd rather fix Wine than ReactOS... Oh well, good luck to both of them.
That depends what you mean by "near as good". I'd say, it has to be hugely better than Windows -- at least as much as OS X is better than OS 9.
No, but that's not Linux's fault either. Apps won't be ported, drivers won't be supplied by manufacturers, until Linux is more popular. Linux won't get more popular until there are apps and drivers.
Chickens and eggs. It's actually impossible for any new OS to enter the market and beat Microsoft right now, because Windows has more stuff because everyone uses Windows because Windows has more stuff.
How many millions of people eat white bread? I was raised on wheat, and I think it tastes better.
How many of the people born and raised on white bread have actually tasted whole wheat bread?
The market share doesn't prove anything other than that more people use Windows. Many of these people may simply not be aware of Linux.
It was something like 50 centavos an hour -- that's half a Sole. The conversion rate is something like three Soles to the dollar.
Pretty much every computer there was some flavor of XP, many on crappy old computers, and always insanely cheap like that. Either it's MUCH cheaper to get Peruvian Windows, or there's a lot of piracy going on. Wouldn't be surprised by either.