The fact that this ''optimization'' is even possible, demonstrates that this protocol is insecure!
If they were able to do this without cooperation of the endpoints, it'd be a man-in-the-middle attack, and yes it would demonstrate that SSL is insecure.
The article's background information skips over an important point: the WAN accelerator device must be owned by the same group that runs the server. So this is for your data centers, not for your corporate headquarters.
I've never heard of this sort of device before, but I'll give my own background, filling in the gaps from their later information, my understanding of SSL, and a couple guesses.
The original (unencrypted) problem: Say you have a low-bandwidth link between a bunch of servers and clients. You want to make the best use of your link's limited bandwidth through compression (as well as QoS and such). In fact, you want to say "these next 426 bytes are the same as chunk 12345, which I've previously sent to some other client". The original setup looks like this:
Server <-slow-> Clients
The solution: obviously you can't say "just access chunk 12345" to client B if you sent chunk 12345 to client A. That's why they use a pair of these devices straddling the slow link to do this compression. They compress when sending and decompress when receiving. In the end, you still need to be able to send all the original bytes to each client. You might have many slow connections, but we'll say it's a "fast" link because in aggregate they're fast enough. So the setup looks like this:
Server <-raw/fast-> Accelerator.Server <-compressed/slow-> Accelerator.Client <-raw/fast-> Clients
Now, I'm not sure how common this setup actually is. Apparently you've cheaped out and gotten a T-1 or something across town, but you still have to pay for all the upstream bandwidth as the data leave your control or diverge. But let's just go with it.
Now add encryption. You could look for commonalities in the encrypted streams, but you're unlikely to find much. For the compression to be effective, it needs to work on unencrypted data. And you can't just forge a certificate on-the-fly to make proxying transparent, unless you've found a man-in-the-middle vulnerability in the SSL setup. Short of that, this is possible under one of two conditions: (1) the validators trust a CA certificate to which the device has a private key, so it can issue new certificates on the fly, or (2) the device has been preloaded with keys for every certificate it is expected to proxy.
The choice they've made seems to be this: you're assumed to control the servers but not the clients. So if you want to have an SSL connection to a given server, you need to load that server's key somewhere onto this pair of devices. (Preferably the Accelerator.Server for security.) That's what they're talking about in this paragraph:
In any SSL proxying architecture, the server must give up its certificates to at least one other device. In the cases of Blue Coat, Certeon and Riverbed, that device is a WAN optimizer that sits inside the data center where it is as physically secure as the server itself....
I'm not sure if they support SSL client authentication, but if they did, the choice is the same: load all the clients' keys onto the device or have your servers trust the device's CA.
Cop is convicted because "everone knows" he did it.
Seems similar to many high-profile trials in which the case is all but closed in the court of public opinion before the justice system moves in. I believe the standard mechanism to restore impartiality is a change of venue. Note that they did this in the Rodney King trial.
Under today's law in the US, the college students can't be charged with anything.
IANAL, but I'd think they'd be sued for libel, or at least slander. I believe they're both civil law, though. For criminal law, see my next point:
The video would never be admitted into court as evidence
I think it would if the alteration slipped past all the experts and the college students testified that they took it themselves and it was an accurate record what happened. Of course, then you'd add perjury and fabricating evidence to their rap sheet, which is far more serious.
But "everyone" knows "seeing is believing" and so they are going to take anything that even looks real as the absolute truth.
Perhaps France is trying to slide away from this, just a little bit
The article said it was an attempt to stop the "happy slappers" - one guy films another performing acts of violence on strangers. Interesting, the USA already has laws against this practice - assault and (I think) being an accomplice to assault. I guess France is a little behind...
I have heard people say they want this for hardware compatibility reasons. Like if Linux came on a Dell, then all the hardware would be compatible. It seems to me though, the solution is not for Dell to use parts that Linux supports, but for Linux to support the parts that Dell is using (to any reasonable extend).
Dell can use their volume as negotiating power with hardware vendors. If the Linux people say "hey, we own your hardware like everyone else who bought a Dell, and we'd like to support it", the hardware vendors don't really care. They already have the money, and they say "there aren't that many Linux people anyway". If Dell says "we'll ship your hardware in millions of machines...but only if you help these Linux guys out," it's a different story.
The same effect seems to be working well for the OLPC project. Hardware vendors apparently become much more flexible when you tell them a purchase of millions of machines is on the line.
Can I mod you 'pedantic moron' for running to the latest iteration of an evolving standard as proof of anything?
No, and unfortunately there's no "poor reading comprehension" mod for me to give to you either. ("Troll" will have to do; someone's given it to you, and it suits your tone.) I'm not trying to prove anything about the history of Unix. I'm just pointing to the latest wisdom of how/etc should be used.
Someone else has answered the original history trivia question. Interesting, but not terribly useful.
Why it was called that is at best a trivia question. A more directly useful question is what it should be used for. The Filesystem Hierarchy Standard version 2.3 (primarily used by Linux people, I think) says this:
The/etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]
IIRC, some other systems (SunOS?) used to put binaries in there, which never made sense to me
Re:a scripting language that targets the java vm !
on
Groovy in Action
·
· Score: 1
[A new process starting every time a user does something in a web interface] was proven not to scale over a decade ago.
You mean that was proven back in the day when a significant percentage of CPU cycles were needed to fork a process? Today I bet it's absolutely a non-issue, and huge layers upon layers of frameworks are likely a much higher burden on both the machine and the developer. (This is not saying that all frameworks, or Java are bad, or that you should do everything CGI. Definitely not. And there's also FastCGI; same idea, but more efficient.)
It sounds like you think these two things (forking a CGI on every hit and using a lot of abstraction layers) have independently computable performance impacts. If you indeed believe that, you're dead wrong - the performance penalty of the abstraction layers is largely paid on startup, so it's negligible in a long-lived process FastCGI, and horrible in a process-per-hit like CGI. In other words, if you measured these four quantities:
A: CPU time/hit for FastCGI script with no framework
B: CPU time/hit for FastCGI script with framework
C: CPU time/hit for CGI script with no framework
D: CPU time/hit for CGI script with framework
You'd find that (D - C) >>> (is much greater than) (B - A). Also that C >>> B. The comparison between A and B will be much closer, and can really go either way.
Why, you ask? fork() is comparatively cheap, yes. That's never been why CGI is horribly expensive. The real cost begins with execv("/usr/bin/perl",...), continues with loading all those modules, and finishes with creating a new RDBMS connection and requerying any otherwise-cacheable state. You seem to be saying "you need to reduce the number of modules to make it fast", but the real answer is make all of those costs 0 - don't redo that work on every request. This is the solution people came up with 10 years ago, and it's more valid now than it ever has been. Those layers of abstraction serve a purpose - they make it much easier to write large systems, and often they provide performance benefits through easy-to-use pooling and caching.
Consequence: A mod_(perl|python|php|ruby), FastCGI, or servlet engine-based system, with or without all those modern layers of abstraction, will mop the floor with a Perl CGI every time. If you doubt that, don't make silly bets on slashdot - just do the benchmark.
Where in California are you that you don't see CFLs everywhere? In the Bay Area you can't get away from them. Seriously, probably 90% of the bulbs I see are CFLs or other high-efficiency lights.
Bay Area also. If they're everywhere, I guess I just didn't notice that they weren't normal bulbs...they're supposed to look the same, right? If their advantage is supposed to be energy efficiency, what would work better is headlines saying "State of California saves $BIGNUM through CFLs". Better to point out the economic impact they already have than create a new artificial one.
I come from Indiana. The difference between midwestern liberals and Californian liberals is that midwestern liberals don't exist. And I know it's hard (again, coming from Indiana) to realize bad != liberal != bad, but don't forget that for the last three and a half years, all this "nanny state" legislation you talk about has been autographed by the Republican governor.
I'd say midwestern liberals exist (and would consider myself one), but "liberal" is a vague word and I think we're disagreeing on its meaning. In the terminology of the two-axis political compass, there are midwestern Democrats who fall more toward the liberatian left, vs. Californian ones who apparently favor the authoritarian left. (And apparently that Republican governator you mention more toward the authoritarian side as well, and presumably more on the right.)
Personally, I'd not want a BAN on incandescents, just a "wattage tax" on lightbulbs, say $4/100W tax on bulbs regardless of the mechanism (LED, CFL, incandescent). Just something equivelent to 1 hour a day use for 1 year (assuming.14 kwh power cost), so that at the register you actually see what the bulb will cost.
I'd want neither bans nor taxes. Rather, leadership by example. Here's what I don't get: the State of California itself purchases a huge number of light bulbs of every sort. Why don't they just pass new procurement rules? If the government itself uses only Compact Fluorescent Lightbulbs (or whatever's trendy), the rest of us Californians will be exposed to them. If the new bulbs really are better, we'll all follow in time.
I come from Iowa. When I got here, people told me about the difference between midwestern liberals and Californian liberals. I'm starting to get it...I don't appreciate this nanny state "we will tell you what kind of light bulbs you must buy" thing.
Partitioning an array is free. Comparisons in an array are O(1). Operations on linked lists mean traversing to the appropriate spot, an O(n) operation. The normal way people count sort operations is by the number of comparisons. If each comparison has a non-constant traversal cost, the cost of the whole is higher. I'm not sure off the top of my head exactly what it is. Tempting to say O(n^2 log n) instead of O(n log n), but since the size of the partitions (which bound the traversal distance) shrink through the sort, it might be O(n log^2 n) or something. I'm curious now; may have to work through the problem and find out.
Hmm. Actually, I guess it is still O(n log n) [*]. Maybe this is what you (vidarh) were talking about: any time you have to traverse to the partition point, you'll also be looking at each element on both sides of it shortly afterward. So the traverse basically just increases your reads by about 50%, which is not an asymptotic difference. It might have a rather unfortunate interaction with the cache, however.
[*] - in the "average case", that is. Quicksort's worst case is O(n^2).
Actually sorting linked lists is useful in many cases
Such as? I won't be so foolish as to claim it's never useful, but I will say there's a reason most of the focus is on sorting arrays.
partitioning a linked list is cheap
Partitioning an array is free. Comparisons in an array are O(1). Operations on linked lists mean traversing to the appropriate spot, an O(n) operation. The normal way people count sort operations is by the number of comparisons. If each comparison has a non-constant traversal cost, the cost of the whole is higher. I'm not sure off the top of my head exactly what it is. Tempting to say O(n^2 log n) instead of O(n log n), but since the size of the partitions (which bound the traversal distance) shrink through the sort, it might be O(n log^2 n) or something. I'm curious now; may have to work through the problem and find out.
and can sometimes be faster than using an array if the objects being sorted are complex and stored by value (i.e. in any case where moving the linked list pointers around would be faster than copying the objects). A variety of other sorts are also easily adaptable to linked lists.
Agreed, but your careful wording implies you've already thought of the other way - an array of references.
Sixth, the headline "10X faster" is incorrect, as they differ asymptotically, not by a constant factor. (Run different data sets...vary by size of a single element, and by number of elements in the list. The ratio will change.)
Why the distinction? The protection level the code is executing in? Drivers running in ring 0 are part of the kernel, drivers in user-space aren't?
That wouldn't be an unreasonable way to define it. The protection levels exist to enforce the split, though - keeping userspace tasks to their business,which the kernel manages by scheduling processes, doling out memory, and providing communication mechanisms. (And in a traditional kernel, other services which haven't been so easy to split off. Hardware drivers require supervisor access, an IO-MMU, or asking the kernel to do things on their behalf (slow); filesystems are intertwined with the memory management.) You bring up systems without memory protection:
If that's the case, are (were) DOS programs part of the MS-DOS kernel? In real mode, there's no concept of kernel vs. user-space, so effectively they're both running in ring 0. (In reality there is no such thing as ring 0 in real mode, so this isn't true.)
Hmm, in addition to not having protection, DOS doesn't do the things kernels do. No scheduler, no IPC, almost no memory management. You might say it has no kernel - it's a bootloader and a set of applications written without the kernel/userspace split.
However, maybe this will get at what you're asking: I currently work on a BSD-like system which runs on a processor without an MMU. There's no ring-0 vs. ring-3 distinction, but we have the traditional design anyway. Even though the system call interface comes down to calling a function pointer instead of executing INT $80 or SYSCALL, the kernel assigns memory to processes and restricts system call arguments to be in the correct regions. It's still responsible for scheduling. The secondary effects follow - different tree, no function calls from kernel into userspace, userspace code makes use of libc and an entirely different set of header files - only include/sys is shared, and even there KERNEL=0 vs. KERNEL=1 divides what's available. So we still have something that looks an awful lot like a kernel. If you just look at any.c file from our system, there will be very little doubt if it belongs to kernel or userspace.
In a microkernel, are the user-level servers part of the OS? In Windows, are the device drivers part of the OS? What if they are built with the user mode framework and run in ring 3?
You're still using the term "operating system" which I just said doesn't actually mean anything. If you substitute the word "kernel", the ambiguity is gone. Are the user-level servers part of the kernel? No. Are Windows device drivers part of the kernel? Pre-Vista, yes. Vista's user mode framework? No.
What is OpenGL? ODBC? SDL? XLib? They aren't part of the Operating System, and yet they're not programs. What are they?
Libraries.
There's no point in getting too pedantic about terms like "operating system" that don't actually have widely-established meanings. There can be absolutely no doubt about what code belongs to the kernel and what code belongs to userspace and what difference that makes. Library vs. application code is pretty clear, too, though at run-time much of that distinction is lost (or even after link-time in the case of static libraries). So now that we've defined what they are in terms of words with actual meanings, who cares whether it's part of the operating system or not?
You know, you're right, it doesn't quite say that. I'm not sure where I got the idea (maybe a different article? there were a couple floating around), but this bit actually discourages me from that belief:
Therefore, [the Court of Appeal] wrote, Sykes was required to prove by clear and convincing evidence not only that the statements Gilbert made on her web site were false, but that they were published with actual malice.
Under that standard, the justices concluded Sykes did not prove a probability of prevailing on the merits of his defamation claim.
If all the lower court had said before was that there was "a probability of prevailing" by proving clear and convincing evidence that Gilbert's statements were false, that's much more preliminary than I thought it was. Anyway, IANAL, and good thing, too.
Seriously how the hell could this not be construed as free-speech? I mean she is simply providing information on a service she is unhappy about in the hopes of educating others. Jeez I'm getting more and more afraid to open my mouth every day.
According to the metnews story, the court decided (and the appeals court did not dispute) that the information she is providing is not true. Among other things, her "after" picture was also after four other surgeries from different doctors. So the information was false and damaging. The appeals court said that in this circumstance, it can't be considered defamatory unless the doctor proved her intent was malicious, and he hadn't done that. Apparently the woman's just crazy...
Sorry to hear that you don't like MySQL, but great to see that you nevertheless take time to read/. postings about us and to post your own. Let us know what "warts" you see in our product and help us improve it. Then perhaps one day you will find that it serves your needs.
I don't like that MySQL does not keep my data safely and securely out of the box. Some examples:
I need to flip a whole set of knobs to make MySQL return failure on invalid data. Apparently TRADITIONAL, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_VALUE_ON_ZERO, NO_ENGINE_SUBSTITUTION, NO_UNSIGNED_SUBTRACTION, NO_ZERO_DATE, NO_ZERO_IN_DATE, ONLY_FULL_GROUP_BY, and STRICT_ALL_TABLES. No other RDBMS even has these knobs, much less has the defaults wrong.
There's no way (that I can find) to completely turn off non-transactional tables. As I understand it, if I forget to tell it when creating a table to make it transactional, it's silently not. If a transaction involves even a single non-transactional table, the whole thing is non-transactional. This makes me nervous.
I don't know if it does an fdatasync() at the right times out of the box on all table types. I need ACID, not doubt.
When users have no password set, anyone can connect without a password. Contrast to PostgreSQL: no one connects without authentication unless you explicitly say so in the configuration file. But it's unobtrusive because local users can authenticate via Unix domain sockets / SO_PASSCRED.
I can't take MySQL seriously until this changes. I understand that you have backward compatibility concerns, but that's life - you pay a price for the poor decisions you've made in the past. You might have to go through a long deprecation period before you can get rid of these knobs. At the very least, don't have them flipped this way unless I start mysqld with the --treat-my-data-as-garbage command-line option.
If you fix this fundamental problem, I'll be impressed. I may not use your product, but I will stop laughing at it.
A SATA 1 interface can transfer at a maximum of 150 megs/s, but your hard drive can't. On sequential reads, you're unlikely to see much higher than 40 megs/s, even 7200 RPM desktop drives don't exceed 70 megs/s yet.
Yeah, you're right. I should have been more skeptical of that number, though usually the specs have real transfer speeds. When I tried it just now, I got 14.8 MiB/s reading from the beginning of the disk. Thought it was faster than that...
$ sudo dd if=/dev/disk0 of=/dev/null bs=1048576 count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 69.151946 secs (15527283 bytes/sec)
But that doesn't change my point. There's a huge difference between sequential scan performance and scattered read performance. For many workloads, the device's latency is the bottleneck. (Or causes the bottleneck...split hairs about definitions and wording if you like, but it's what makes it slow.)
You could turn it around and say that, since the disks are not using their full bandwidth, the disks spend most of their time waiting for requests.
Only by specious reasoning. I'll disprove by counterexample. If I continously tell the disk to seek to one extreme and read a cacheful, then seek to the other extreme and read a cacheful, it will neither be waiting for requests nor using its full bandwidth. A and not B disproves (A => B).
Latency and throughput are unrelated only if there can be infinitely many requests produced and satisfied in parallel. In the case of a hard disk, there can be only one active request per head because it can only be at one place at once. Let's consider the example of my laptop hard drive. It's rated at a data transfer rate of 150 MB/s. But look at the seek speeds - 1.5ms minimum, 12ms average read, 22 ms maximum. It can read a 1 MB file in 6.7 ms, but if that 1 MB file is fragmented into ten chunks across the drive, it'll take around 130 ms.[*] So in this case it actually transfers at 5% of its rated speed. And depending on the application, the data may be in many, many tiny chunks.
That being said, disk latency is one of the major causes of poor performance. But "bottlenecks" only have to do with throughput.
Latency limits throughput. The requestee usually can only satisfy a limited number of requests at once (see above), and the requestor may not be able to produce the next request until it's received the previous response.
Simple example: I'm performing a binary search. I need to see what's at location mid before I know if I'll next be interested in location (low+mid)/2 or location (mid+high)/2. In some cases, I can do a speculative fetch for both locations, but you can only extend that out so many generations before you've used up most of your bandwidth on data you'll never use.
Processors are smart about re-ordering instructions to keep working while they're waiting for stuff to happen, but still they frequently get to a point where they can't execute anything more because of ordering constraints - the results of some instruction are dependent on a previous instruction that hasn't completed yet because it's waiting for a value from memory. That value can be the actual instruction to be executed or an operand...either way, your shiny new processor's stuck doing nothing.
[*] - It might beat the average if it's smart about ordering. At the very least, 22 ms has to get added if one request is at one extreme and one request is at the other extreme. That brings it down to 23% of the rated speed.
I'd always set domains up with a catchall that sends unspecified userids to a mailbox, and it's gotten to where for domains that have been around for some years most of the spam coming in is addressed to fake addresses that have been created evidently by other spam faking being from the domain, and then harvested somewhere. Since I've also handed out addresses like amazon@domain.com to track merchants who leak addresses, can't remember them all but still want some of that merchant mail, just sending all this to/dev/null isn't the answer.
I had a catchall until recently, too. I finally got tired of all the catchall spam, wrote a script that dug out all the amazon@example.com style addresses I'd received mail through in the past several years, aliased those[*], and got rid of my catchall. It's made a huge difference in my volume of spam. I didn't gather all the statistics I should have, but I can see right now that it reduced spam not caught by earlier Postfix rules with SpamAssassin scores under 8.0 by 83% in the week before the change vs. the week after the change (from 1,738 to 302; made the change the week before Christmas). This wasn't a rigorous experiment - for starters, I had no control. But rejecting catchall email eliminated most of the spam that actually made it into my mailbox, and an even greater percentage of the spam my poor machine had to feed through SpamAssassin.
Point is: if your spam is still bad after your recent 90% reduction, bite the bullet, figure out which email addresses you've given out to vendors, whitelist them, and get rid of the catchall. Your inbox will thank you.
But the array of spammers that target me and those that target someone else may well differ greatly. Maybe someone else gets heavily spammed by secondary-MX targeters even though I'm not.
Could be. It would be interesting to see experiments showing how effective different antispam techniques are on different user demographics when starting from the same base mail setup. It'd have to be repeated frequently, too, as spammers change over time. There are a lot of variables.
[*] - and am now slowly going to vendors' websites, switching my email address to something like me+amazon@example.com, and removing the old aliases. Turns out there's very little spam going to the aliased entries, but the long list offends my aesthetic sense.
Most spam bots already send to the *lowest* priority MX (ie. the highest number), and work their way backwards, because it's common for the backup MX'es to have lower anti-spam rules.
Do you have any experimental results to back up your claim? Any actual reason to believe it's true? Because he has results that dispute it. Read the article. In his quick experiment, 47% of confirmed spammers tried the primary only, 36% tried the secondary only, and only 17% tried both. While possible that his sample is skewed or that spammers have adapted since his experiment was performed (page was Last-Modified: Sun, 12 Nov 2006), I'm much more inclined to believe the guy who has done his homework over the guy shooting from the hip on slashdot.
The only real objection I've heard on slashdot is that spammers will adapt. Could be true. The author thinks his technique will never be common enough for spammers to bother adapting to, but they may alter this behavior as a side effect of adapting to more common techniques like grey-listing.
I think I'll give it a try. It's trivial to set up and has an extremely low risk of losing legitimate mail. If it doesn't work, I've lost only a few minutes of time.
You're correct - SMTP already supports that. I use spampd as a Postfix before-queue content filter. If someone tries to send me spam (and has gotten past the client, HELO, sender, recipient, and rate/concurrency limiting checks), my machine says this in response to the DATA command:
550 5.7.1 SpamAssassin score is too high.
(My SMTP response is worded somewhat politely because while the probability that the message is spam is quite high, the probability that the message is spam given that someone is reading my response is quite low. Write the message for the friendly mail administrator, not for the evil spammer.)
There are significant downsides to this approach, however. SpamAssassin is very memory-hungry. I can only be spam-checking so many simultaneously. This limits my mailserver's maximum concurrency. And if my system processes messages too quickly, the remote mailserver will give up on me and I'll have to go through it all again when they come back.
I used to say that everyone should be using this approach, but it's probably not realistic for large sites. They need to level out the load by inserting a queue between receipt and spam checking. That means accepting the message for delivery before knowing if it's good and thus bouncing it on failure.
What may be more realistic is rejecting bounces regarding messages that you know were forged. Your system can keep a database of all outbound Message-IDs, and bounces are in a well-defined format. (Aside from those stupid pseudo-bounces from the !@#$ virus checkers; I hate those.) If a bounce refers to a Message-ID that you haven't sent, the bounce can be rejected.
The thing is your 1GHz mac is using a CPU instead of a dedicated ciruit, and is playing at very high resolutions, along with OS overhead. A player can use a minimal OS, a dedicated chip, and low resolution.
Wrong on all points. The players would decode with the CPU as well, unless you're expecting separate hardware for each of these half-dozen codecs you're demanding. Low resolutions don't help enough - I've seen skipping playing a 480i (SDTV) clip, and whether I'm viewing that in a tiny window or scaling it up to be full-screen makes little difference to the pegged CPU. OS overhead is insignificant - it's easy to measure, since OS X distinguishes between the user time of the Quicktime/VLC/whatever process, system time, and time used by other processes such as the window server. The decoding itself is where the CPU time is going.
- Plays music directly off its filesystem (which can be accessed as a USB mass storage device), so I don't need software!
Not easy to do well. Either it has a horrible UI (like all of the no-name players you mention) which can't handle searching by ID3 tags, or it has to do its own indexing. The latter is not easy - even recognizing when new files show up is not trivial, given that the computer is talking to it through the USB mass storage interface as a block device! It would have to have some weird code to translate the block requests back into filesystem requests and check on each request until the whole file shows up, or just suspend while talking to the computer (no music when it's plugged in) and walk the entire filesystem for changes afterward (probably slow).
- Has a mini-USB connector for sync and charge
I think mini-USB connectors have extreme current limitations. It'd either have low battery life or would take forever to charge. Is carrying around the (included) iPod cable so much of a problem that you're willing to accept that tradeoff?
- Plays MPEG-1, MPEG-2, XVID, and H.264 (with a decent range of resolution and bitrate options, bonus points for FLV support)
My 1GHz G4 PowerBook skips when playing fancier, newer codecs. Do you think they can make an affordable, low-power, miniaturized system that has even a fighting chance?
- Has a decent UI
Development and UI testing take time and money. There doesn't seem to be much money left after the cost of your hardware, and sometimes design choices are incompatible with having a good UI. There are certain patented interface options (scroll wheel, some touch screen stuff now) not available to most vendors, either.
- Is as small as an iPod Nano
Miniaturization is expensive, and flash is still more expensive than spindle. You were just talking about video, so you probably want a lot of space, too.
Why can't someone do this? All of the no-name players have the feature list down, but they invariably have crappy UIs and/or crappy form factors.
You've listed a bunch of features which aren't that important to most consumers yet would cripple the product and send its cost through the roof. If these no-name players do all of these...well, no wonder why they're no-name players. They made poor design decisions.
Slashdot Mirror
If they were able to do this without cooperation of the endpoints, it'd be a man-in-the-middle attack, and yes it would demonstrate that SSL is insecure.
The article's background information skips over an important point: the WAN accelerator device must be owned by the same group that runs the server. So this is for your data centers, not for your corporate headquarters.
I've never heard of this sort of device before, but I'll give my own background, filling in the gaps from their later information, my understanding of SSL, and a couple guesses.
The original (unencrypted) problem: Say you have a low-bandwidth link between a bunch of servers and clients. You want to make the best use of your link's limited bandwidth through compression (as well as QoS and such). In fact, you want to say "these next 426 bytes are the same as chunk 12345, which I've previously sent to some other client". The original setup looks like this:
The solution: obviously you can't say "just access chunk 12345" to client B if you sent chunk 12345 to client A. That's why they use a pair of these devices straddling the slow link to do this compression. They compress when sending and decompress when receiving. In the end, you still need to be able to send all the original bytes to each client. You might have many slow connections, but we'll say it's a "fast" link because in aggregate they're fast enough. So the setup looks like this:
Now, I'm not sure how common this setup actually is. Apparently you've cheaped out and gotten a T-1 or something across town, but you still have to pay for all the upstream bandwidth as the data leave your control or diverge. But let's just go with it.
Now add encryption. You could look for commonalities in the encrypted streams, but you're unlikely to find much. For the compression to be effective, it needs to work on unencrypted data. And you can't just forge a certificate on-the-fly to make proxying transparent, unless you've found a man-in-the-middle vulnerability in the SSL setup. Short of that, this is possible under one of two conditions: (1) the validators trust a CA certificate to which the device has a private key, so it can issue new certificates on the fly, or (2) the device has been preloaded with keys for every certificate it is expected to proxy.
The choice they've made seems to be this: you're assumed to control the servers but not the clients. So if you want to have an SSL connection to a given server, you need to load that server's key somewhere onto this pair of devices. (Preferably the Accelerator.Server for security.) That's what they're talking about in this paragraph:
I'm not sure if they support SSL client authentication, but if they did, the choice is the same: load all the clients' keys onto the device or have your servers trust the device's CA.
Seems similar to many high-profile trials in which the case is all but closed in the court of public opinion before the justice system moves in. I believe the standard mechanism to restore impartiality is a change of venue. Note that they did this in the Rodney King trial.
IANAL, but I'd think they'd be sued for libel, or at least slander. I believe they're both civil law, though. For criminal law, see my next point:
I think it would if the alteration slipped past all the experts and the college students testified that they took it themselves and it was an accurate record what happened. Of course, then you'd add perjury and fabricating evidence to their rap sheet, which is far more serious.
The article said it was an attempt to stop the "happy slappers" - one guy films another performing acts of violence on strangers. Interesting, the USA already has laws against this practice - assault and (I think) being an accomplice to assault. I guess France is a little behind...
Dell can use their volume as negotiating power with hardware vendors. If the Linux people say "hey, we own your hardware like everyone else who bought a Dell, and we'd like to support it", the hardware vendors don't really care. They already have the money, and they say "there aren't that many Linux people anyway". If Dell says "we'll ship your hardware in millions of machines...but only if you help these Linux guys out," it's a different story.
The same effect seems to be working well for the OLPC project. Hardware vendors apparently become much more flexible when you tell them a purchase of millions of machines is on the line.
No, and unfortunately there's no "poor reading comprehension" mod for me to give to you either. ("Troll" will have to do; someone's given it to you, and it suits your tone.) I'm not trying to prove anything about the history of Unix. I'm just pointing to the latest wisdom of how /etc should be used.
Someone else has answered the original history trivia question. Interesting, but not terribly useful.
IIRC, some other systems (SunOS?) used to put binaries in there, which never made sense to me
It sounds like you think these two things (forking a CGI on every hit and using a lot of abstraction layers) have independently computable performance impacts. If you indeed believe that, you're dead wrong - the performance penalty of the abstraction layers is largely paid on startup, so it's negligible in a long-lived process FastCGI, and horrible in a process-per-hit like CGI. In other words, if you measured these four quantities:
You'd find that (D - C) >>> (is much greater than) (B - A). Also that C >>> B. The comparison between A and B will be much closer, and can really go either way.
Why, you ask? fork() is comparatively cheap, yes. That's never been why CGI is horribly expensive. The real cost begins with execv("/usr/bin/perl", ...), continues with loading all those modules, and finishes with creating a new RDBMS connection and requerying any otherwise-cacheable state. You seem to be saying "you need to reduce the number of modules to make it fast", but the real answer is make all of those costs 0 - don't redo that work on every request. This is the solution people came up with 10 years ago, and it's more valid now than it ever has been. Those layers of abstraction serve a purpose - they make it much easier to write large systems, and often they provide performance benefits through easy-to-use pooling and caching.
Consequence: A mod_(perl|python|php|ruby), FastCGI, or servlet engine-based system, with or without all those modern layers of abstraction, will mop the floor with a Perl CGI every time. If you doubt that, don't make silly bets on slashdot - just do the benchmark.
Bay Area also. If they're everywhere, I guess I just didn't notice that they weren't normal bulbs...they're supposed to look the same, right? If their advantage is supposed to be energy efficiency, what would work better is headlines saying "State of California saves $BIGNUM through CFLs". Better to point out the economic impact they already have than create a new artificial one.
I'd say midwestern liberals exist (and would consider myself one), but "liberal" is a vague word and I think we're disagreeing on its meaning. In the terminology of the two-axis political compass, there are midwestern Democrats who fall more toward the liberatian left, vs. Californian ones who apparently favor the authoritarian left. (And apparently that Republican governator you mention more toward the authoritarian side as well, and presumably more on the right.)
I'd want neither bans nor taxes. Rather, leadership by example. Here's what I don't get: the State of California itself purchases a huge number of light bulbs of every sort. Why don't they just pass new procurement rules? If the government itself uses only Compact Fluorescent Lightbulbs (or whatever's trendy), the rest of us Californians will be exposed to them. If the new bulbs really are better, we'll all follow in time.
I come from Iowa. When I got here, people told me about the difference between midwestern liberals and Californian liberals. I'm starting to get it...I don't appreciate this nanny state "we will tell you what kind of light bulbs you must buy" thing.
Hmm. Actually, I guess it is still O(n log n) [*]. Maybe this is what you (vidarh) were talking about: any time you have to traverse to the partition point, you'll also be looking at each element on both sides of it shortly afterward. So the traverse basically just increases your reads by about 50%, which is not an asymptotic difference. It might have a rather unfortunate interaction with the cache, however.
[*] - in the "average case", that is. Quicksort's worst case is O(n^2).
Such as? I won't be so foolish as to claim it's never useful, but I will say there's a reason most of the focus is on sorting arrays.
Partitioning an array is free. Comparisons in an array are O(1). Operations on linked lists mean traversing to the appropriate spot, an O(n) operation. The normal way people count sort operations is by the number of comparisons. If each comparison has a non-constant traversal cost, the cost of the whole is higher. I'm not sure off the top of my head exactly what it is. Tempting to say O(n^2 log n) instead of O(n log n), but since the size of the partitions (which bound the traversal distance) shrink through the sort, it might be O(n log^2 n) or something. I'm curious now; may have to work through the problem and find out.
Agreed, but your careful wording implies you've already thought of the other way - an array of references.
Sixth, the headline "10X faster" is incorrect, as they differ asymptotically, not by a constant factor. (Run different data sets...vary by size of a single element, and by number of elements in the list. The ratio will change.)
Hmm, in addition to not having protection, DOS doesn't do the things kernels do. No scheduler, no IPC, almost no memory management. You might say it has no kernel - it's a bootloader and a set of applications written without the kernel/userspace split.
However, maybe this will get at what you're asking: I currently work on a BSD-like system which runs on a processor without an MMU. There's no ring-0 vs. ring-3 distinction, but we have the traditional design anyway. Even though the system call interface comes down to calling a function pointer instead of executing INT $80 or SYSCALL, the kernel assigns memory to processes and restricts system call arguments to be in the correct regions. It's still responsible for scheduling. The secondary effects follow - different tree, no function calls from kernel into userspace, userspace code makes use of libc and an entirely different set of header files - only include/sys is shared, and even there KERNEL=0 vs. KERNEL=1 divides what's available. So we still have something that looks an awful lot like a kernel. If you just look at any .c file from our system, there will be very little doubt if it belongs to kernel or userspace.
You're still using the term "operating system" which I just said doesn't actually mean anything. If you substitute the word "kernel", the ambiguity is gone. Are the user-level servers part of the kernel? No. Are Windows device drivers part of the kernel? Pre-Vista, yes. Vista's user mode framework? No.
Libraries.
There's no point in getting too pedantic about terms like "operating system" that don't actually have widely-established meanings. There can be absolutely no doubt about what code belongs to the kernel and what code belongs to userspace and what difference that makes. Library vs. application code is pretty clear, too, though at run-time much of that distinction is lost (or even after link-time in the case of static libraries). So now that we've defined what they are in terms of words with actual meanings, who cares whether it's part of the operating system or not?
If all the lower court had said before was that there was "a probability of prevailing" by proving clear and convincing evidence that Gilbert's statements were false, that's much more preliminary than I thought it was. Anyway, IANAL, and good thing, too.
I don't like that MySQL does not keep my data safely and securely out of the box. Some examples:
I can't take MySQL seriously until this changes. I understand that you have backward compatibility concerns, but that's life - you pay a price for the poor decisions you've made in the past. You might have to go through a long deprecation period before you can get rid of these knobs. At the very least, don't have them flipped this way unless I start mysqld with the --treat-my-data-as-garbage command-line option.
If you fix this fundamental problem, I'll be impressed. I may not use your product, but I will stop laughing at it.
$ sudo dd if=/dev/disk0 of=/dev/null bs=1048576 count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 69.151946 secs (15527283 bytes/sec)
But that doesn't change my point. There's a huge difference between sequential scan performance and scattered read performance. For many workloads, the device's latency is the bottleneck. (Or causes the bottleneck...split hairs about definitions and wording if you like, but it's what makes it slow.)
Only by specious reasoning. I'll disprove by counterexample. If I continously tell the disk to seek to one extreme and read a cacheful, then seek to the other extreme and read a cacheful, it will neither be waiting for requests nor using its full bandwidth. A and not B disproves (A => B).
Latency and throughput are unrelated only if there can be infinitely many requests produced and satisfied in parallel. In the case of a hard disk, there can be only one active request per head because it can only be at one place at once. Let's consider the example of my laptop hard drive. It's rated at a data transfer rate of 150 MB/s. But look at the seek speeds - 1.5ms minimum, 12ms average read, 22 ms maximum. It can read a 1 MB file in 6.7 ms, but if that 1 MB file is fragmented into ten chunks across the drive, it'll take around 130 ms.[*] So in this case it actually transfers at 5% of its rated speed. And depending on the application, the data may be in many, many tiny chunks.
Latency limits throughput. The requestee usually can only satisfy a limited number of requests at once (see above), and the requestor may not be able to produce the next request until it's received the previous response.
Simple example: I'm performing a binary search. I need to see what's at location mid before I know if I'll next be interested in location (low+mid)/2 or location (mid+high)/2. In some cases, I can do a speculative fetch for both locations, but you can only extend that out so many generations before you've used up most of your bandwidth on data you'll never use.
Processors are smart about re-ordering instructions to keep working while they're waiting for stuff to happen, but still they frequently get to a point where they can't execute anything more because of ordering constraints - the results of some instruction are dependent on a previous instruction that hasn't completed yet because it's waiting for a value from memory. That value can be the actual instruction to be executed or an operand...either way, your shiny new processor's stuck doing nothing.
[*] - It might beat the average if it's smart about ordering. At the very least, 22 ms has to get added if one request is at one extreme and one request is at the other extreme. That brings it down to 23% of the rated speed.
I had a catchall until recently, too. I finally got tired of all the catchall spam, wrote a script that dug out all the amazon@example.com style addresses I'd received mail through in the past several years, aliased those[*], and got rid of my catchall. It's made a huge difference in my volume of spam. I didn't gather all the statistics I should have, but I can see right now that it reduced spam not caught by earlier Postfix rules with SpamAssassin scores under 8.0 by 83% in the week before the change vs. the week after the change (from 1,738 to 302; made the change the week before Christmas). This wasn't a rigorous experiment - for starters, I had no control. But rejecting catchall email eliminated most of the spam that actually made it into my mailbox, and an even greater percentage of the spam my poor machine had to feed through SpamAssassin.
Point is: if your spam is still bad after your recent 90% reduction, bite the bullet, figure out which email addresses you've given out to vendors, whitelist them, and get rid of the catchall. Your inbox will thank you.
Could be. It would be interesting to see experiments showing how effective different antispam techniques are on different user demographics when starting from the same base mail setup. It'd have to be repeated frequently, too, as spammers change over time. There are a lot of variables.
[*] - and am now slowly going to vendors' websites, switching my email address to something like me+amazon@example.com, and removing the old aliases. Turns out there's very little spam going to the aliased entries, but the long list offends my aesthetic sense.
Do you have any experimental results to back up your claim? Any actual reason to believe it's true? Because he has results that dispute it. Read the article. In his quick experiment, 47% of confirmed spammers tried the primary only, 36% tried the secondary only, and only 17% tried both. While possible that his sample is skewed or that spammers have adapted since his experiment was performed (page was Last-Modified: Sun, 12 Nov 2006), I'm much more inclined to believe the guy who has done his homework over the guy shooting from the hip on slashdot.
The only real objection I've heard on slashdot is that spammers will adapt. Could be true. The author thinks his technique will never be common enough for spammers to bother adapting to, but they may alter this behavior as a side effect of adapting to more common techniques like grey-listing.
I think I'll give it a try. It's trivial to set up and has an extremely low risk of losing legitimate mail. If it doesn't work, I've lost only a few minutes of time.
(My SMTP response is worded somewhat politely because while the probability that the message is spam is quite high, the probability that the message is spam given that someone is reading my response is quite low. Write the message for the friendly mail administrator, not for the evil spammer.)
There are significant downsides to this approach, however. SpamAssassin is very memory-hungry. I can only be spam-checking so many simultaneously. This limits my mailserver's maximum concurrency. And if my system processes messages too quickly, the remote mailserver will give up on me and I'll have to go through it all again when they come back.
I used to say that everyone should be using this approach, but it's probably not realistic for large sites. They need to level out the load by inserting a queue between receipt and spam checking. That means accepting the message for delivery before knowing if it's good and thus bouncing it on failure.
What may be more realistic is rejecting bounces regarding messages that you know were forged. Your system can keep a database of all outbound Message-IDs, and bounces are in a well-defined format. (Aside from those stupid pseudo-bounces from the !@#$ virus checkers; I hate those.) If a bounce refers to a Message-ID that you haven't sent, the bounce can be rejected.
How did you determine that it's a power hog? If by the battery not lasting very long, you've made my point.
Ahh, the old straw man. Nicely played.
Wrong on all points. The players would decode with the CPU as well, unless you're expecting separate hardware for each of these half-dozen codecs you're demanding. Low resolutions don't help enough - I've seen skipping playing a 480i (SDTV) clip, and whether I'm viewing that in a tiny window or scaling it up to be full-screen makes little difference to the pegged CPU. OS overhead is insignificant - it's easy to measure, since OS X distinguishes between the user time of the Quicktime/VLC/whatever process, system time, and time used by other processes such as the window server. The decoding itself is where the CPU time is going.
Your feature list would cripple the product.
Not easy to do well. Either it has a horrible UI (like all of the no-name players you mention) which can't handle searching by ID3 tags, or it has to do its own indexing. The latter is not easy - even recognizing when new files show up is not trivial, given that the computer is talking to it through the USB mass storage interface as a block device! It would have to have some weird code to translate the block requests back into filesystem requests and check on each request until the whole file shows up, or just suspend while talking to the computer (no music when it's plugged in) and walk the entire filesystem for changes afterward (probably slow).
I think mini-USB connectors have extreme current limitations. It'd either have low battery life or would take forever to charge. Is carrying around the (included) iPod cable so much of a problem that you're willing to accept that tradeoff?
My 1GHz G4 PowerBook skips when playing fancier, newer codecs. Do you think they can make an affordable, low-power, miniaturized system that has even a fighting chance?
Development and UI testing take time and money. There doesn't seem to be much money left after the cost of your hardware, and sometimes design choices are incompatible with having a good UI. There are certain patented interface options (scroll wheel, some touch screen stuff now) not available to most vendors, either.
Miniaturization is expensive, and flash is still more expensive than spindle. You were just talking about video, so you probably want a lot of space, too.
You've listed a bunch of features which aren't that important to most consumers yet would cripple the product and send its cost through the roof. If these no-name players do all of these...well, no wonder why they're no-name players. They made poor design decisions.