your router is being asked for permission, and it's not only granting it, it's assisting by providing an IP address for you to use and telling you where you might find a good DNS server or two.
More than that. Before it's even asked, it is broadcasting that it will give permission to anyone who asks.
It's not just "leaving the door unlocked" -- this is more equivalent to leaving the door unlocked, and posting a sign outside with big flashing lights that says "Unlocked door here!" -- and then going down to your local public access television and doing a show called "Did you know my door is unlocked? Here's my address! I'll be happy to let you in!"
And as someone else points out, part of the problem is that those of us who genuinely did intend for the access point to be open to all comers no longer have a technological way of advertising that.
Actual "ramdisk" -- that is, like/dev/rd -- that is, appears as a block device. You can run whatever filesystem you want on it, but it's still serializing and writing out to... well, RAM, in this case. No sane way for the kernel to free space on that "disk" that's not actually used.
How I wish it worked:
No Linux that I know of has used an actual ramdisk in forever. Instead, we use tmpfs -- a filesystem which actually grows or shrinks to our needs, up to an optional configurable maximum size. It'll use swap if available/needed. It's basically a RAM filesystem, instead of a RAM disk.
Even initrds are dead now -- we use initramfs. Basically, instead of the kernel booting and reading a ramdisk image directly to/dev/rd0, it instead boots and unpacks a cpio archive (like a tarball, but different/better/worse) into a tmpfs filesystem, and uses that.
So, how I would like this to work is, use a tmpfs filesystem -- as I suspect it will be faster, and in any case simpler, than a ramdisk -- and back it to a real filesystem on-disk. The only challenge here is that it's not as deterministic -- it would be more like a cp than a dd.
An even better (crazier) idea:
Use a filesystem like XFS or Reiser4 -- something which delays allocation until a flush. In either case, it would take a bit of tweaking -- you want to make sure no writes, or fsyncs, block while writing to disk, so long as the power is on -- but you'll hopefully already be caching an obscene amount anyway, so reads will be fast.
In this case, forcing everything out to disk could be as simple as "mount / -o remount,sync" -- or something similar -- forcing an immediate sync, and all future writes to be synchronous.
Conclusion:
Either of the two ideas I suggested should work, and could perform better than a traditional ramdisk. If it is, in fact, a simple disk-backed ramdisk (not ram filesystem), then it's both not as flexible (what if your app suddenly wants 50 gigs of RAM in application space?) and a bit of a hack -- probably a hack around traditional disk-backed filesystems not being able to take advantage of so much RAM by themselves.
In fact, glancing back at TFA, it seems there are some inherent reliability concerns, too:
If UPS power runs out while ramback still holds unflushed dirty data then things get ugly. Hopefully a fsck -f will be able to pull something useful out of the mess. (This is where you might want to be running Ext3.)
Now, true, this should never happen, but in the event it does, the inherent problem here is that the ramdisk doesn't know anything about the filesystem, and so it doesn't know in what order it should be writing stuff to disk. Ext3 journaling makes NO sense for a ramdisk when the ramdisk itself knows nothing about the journal -- the journal is just going to slow down the RAM-based operation. Compare this to a sync call to XFS -- individual files might be corrupted, but all the writes will be journaled in some way, so at least the filesystem structure will be intact.
This gets even better with something like Reiser4's (vaporware) transaction API. If the application can define a transaction at the filesystem level, then this consistent-dump-to-disk will happen at the application level, too. Which means that while it would certainly suck to have a UPS fail, it wouldn't be much worse than the same happening to a non-ramdisk device, at least as far as consistency goes. (Some data will be lost, no way around that, but at least this way, some data will be fine.)
We "accept" the dangers created by the stupidity of those around us because government heavily repress our primal responses.
Government, and social pressures, and...
Wait a second, isn't this horribly offtopic? Not all dangers on the road are created by stupidity. Even if there was no one else around, no weather conditions, perfectly clear road, etc, you're still quite literally taking your life into your hands. The faster you're going, the less of a mistake (or deliberate twitch of the wheel, if you're feeling suicidal) is required to end your life.
Certainly, it'd still be a lot safer without these other people, but I don't think that was the point.
I'm digging, digging, digging and not finding this "acceptance" whereof you speak within myself.
It's caused by you actually driving, rather than walking, biking, flying, grabbing a train, etc.
Not that I expect you to stop driving. I'm just pointing out that you don't actually have a need to drive. Therefore, you're making a choice, consciously or unconsciously, to drive or not to drive. If you choose to drive, knowing the roads are going to be dangerous -- whether caused by idiots or not -- you still chose to take that risk, rather than avoid it. And you probably chose it for the convenience it would bring.
It's a different context than what you dug up -- certainly, we shouldn't passively accept that other people will be assholes on the road. In fact, when I find people tailgating me, I like to hit the brakes. Either they actually do slam into me, in which case, it's their fault -- I can claim to have seen a deer or something -- or it at least demonstrates to them the danger of being too close, especially being too close to me. Either way, they're off my ass.
That seems like a very odd mistake to make -- off the top of my head, I could probably guess array.count, or array.size, array.length, etc. I probably wouldn't know about array.lastIndex, let alone array.lastIndex.indexNum.
even once the students and teachers knew that there was a killer stalking the halls and shooting people they could not stop him because they did not have doors with locks.
That's because the C (and C++, among others) parser is greedy....
It's still an ambiguous case, and one that a newbie is fairly likely to hit. There are languages that have none of these problems (lisp), and languages that have far fewer of these problems (Ruby).
The closest I see to that with Ruby (or Perl) is the fact that both have a lot of syntax which is optional in cases where it can be implied. And most of the time, if you hit a case like this, the resolution is obvious -- just add more parentheses. The solution to issues like that template syntax thing is simply not as obvious.
that doesn't mean it's not an incredibly powerful tool.
I see it as powerful the way C is powerful -- Turing-complete, runs fast, and you can build other languages in it, if needed.
Yes, there are interesting things you can do with the object-orientedness. But they are not half as interesting as what is possible in newer languages, IMNSHO. A little basic reflection goes a long way, among other things...
Don't slag it off just because you don't like template syntax.:)
I also like open classes/modules, closures, mixins, and garbage collection, and I don't like such a strict static type system, pointers as integers, the operator overloading used for IO (seriously, std::cout
I mean, I don't like templates in general. I'm hooked on Ruby's duck typing.
I am sure that a lot of these can be worked around or tacked on in various ways, but why bother, when there are already better languages out there?
I suppose we bother because of performance (sometimes) and legacy projects. And maybe Windows drivers. But I can't really think of any other good reasons.
Commit GMail/etc code secretly backdoored by a hacker.
That seems a bit absurd. Aside from code being reviewed on commit, or periodically, do you think they'd be able to actually deploy it to gmail.com without it being caught first? I really hope they're testing things separately and internally before making them live, even if it is a "beta" product.
Sure you'd get fired when you finally get caught, but if the BSA raids the company before you're found out it could be major fines the company is responsible for.
Seems to me they could just as easily turn around and sue you for abuse of company property. I'm sure you signed an agreement with what you're legally allowed to do (or not do) with company equipment. And if it was your own equipment, it's even less their problem.
Even barring that, there's lots of ways to misplace license keys, and the BSA won't cut you any slack unless you've got damned good records.
Well, they did mention places you could go to grab software. I imagine just about any software you need to do your work, you can get through official channels. Thus, any software that's not kosher could fall back on "Well, we provided all this legitimate stuff for the employee, it's not our fault they did something different."
Disclaimer: I don't actually know how this would work. I am not a lawyer. I don't even play one on TV.
Alternate disclaimer: We were talking about security, not licenses, right? Is this offtopic?
The first hacker to take down their network, either internal or external facing, would be infamous.
And traditional viruses/spyware won't do that.
The trouble is, modern OSes are reasonably secure at this point, and you can bet the external-facing IPs are going to be locked down. Same with internal services -- some random developer's desktop might be open, but the service is going to be secure. So what you're talking about is someone actively making a "hacking" attempt at something that, to my mind, looks pretty much impenetrable.
The only other option is something more insidious -- set up a website which exploits some browser flaw, then hope someone at Google sees it. Or sit around a wifi hotspot, praying that someone logs on with a laptop that's vulnerable, infect it, set it to phone home, then pray it is actually able to phone home, and that Google doesn't take a peek at exactly where it's phoning home to.
And a successful variation of this is still just going to give you the one insecure machine. It's not going to give you the entire network. It's probably got less of a chance of doing that than if they were extremely anal-retentive in their security policy (and refused local-admin rights, etc), because it's going to be a heterogenious network.
But then, you did just provide the perfect counterargument: The first hacker to take down their network, either internal or external facing, would be infamous. Therefore, people are trying. It's not working. Therefore, whatever Google is doing for security is working.
That's got nothing to do with my point about a subscription scheme.
No, but the bit about Netflix does. Netflix physical DVD rentals rely on no more DRM than CSS, for which the crack takes up less space than this post. They basically rely on people not knowing how to rip and burn DVDs -- except there are one-click programs to do exactly that.
The reason you keep your netflix subscription is, you want to have something new to watch. (Or something old that you haven't seen yet.) And that's why you'd keep a subscription to any DRM-free service -- because they'd bring you new content. If they stopped doing that, you could cancel your subscription.
Which is why a subscription scheme is a daft idea... it's even more dependent on DRM.
Except it really isn't.
It'd be tricky to do, but it could certainly work, and it would make money. The only downside is, no one would buy individual songs or albums ever again, so it'd be difficult to get the producers sold on such a model. Right now, DRM'd stuff is seen as somewhat safer, as there's always that looming threat of losing your entire collection if you stop paying for it -- which means that either revenue keeps coming in, or people lose the music and have to start buying CDs again.
Yeh, I can't imagine this happening without DRM...
I can.
To beat piracy, you must provide better service, not worse. As long as there are Flac torrents out there, I will never buy DRM'd AACs. But when I do find a band I like selling Flac downloads, I buy them.
Understand, DVDs almost do not count anymore, as CSS has been braken everywhere for years, and every new scheme is more desperate and futile than the last -- yet NetFlix still makes money. If Apple provided this service without the DRM, they would still make money, so long as there was new and interesting music.
it would mean a serious reversion of Apple's DRM policy.
Well, as the other article shows, Steve Jobs habitually lies about this kind of thing. Probably half of Apple, never mind the rest of the world, assumed that Apple was going to stay the course with PowerPC, right up until the Intel macs were released. Steve had to know about this, yet he let the Apple.com site continue to spew BS about the G5's "intel-crushing performance"... Again, right up to (and maybe a bit past) the point at which they went Intel.
Because it's cheap and tiny. And because no one else has made a fully functional computer that is this cheap and this small -- generally, it's been just the opposite, where smaller costs more.
If they were able to put something comparable to even an AMD X2 processor into it
You speak as if an X2 is slow?
And...
As for me, I want to carry around something faster than my PC
Why? Seriously, why?
What is it that you need to do on the train, bus, plane, in a car, in the park, etc, that requires a dual-core processor? Under what circumstances do you need to do something that requires that much power, and you can't simply go back to a desktop somewhere? Or even remote to one?
these things would be crazy popular!
They are. Or didn't you notice?
And before anyone says it, yes it's all because of battery life.
That makes even less sense.
You want something extremely powerful, so that it can use less battery life? WTF?
Here's a hint: All the computers I currently own tend to clock themselves back to 1 ghz, in order to save power. Why is it that you think a faster processor would give you more battery life? A newer one, sure, but not a faster one.
It might also be worth investigating how big a battery you can buy for the eee, or how cheap they are. It's not exactly pleasant, but you can certainly shut down, swap batteries, and boot again -- assuming it doesn't have a couple minutes of onboard battery (probably not, but maybe). Or give it some extra storage and figure out how to make it hibernate while you do that. Or find an outlet and plug in -- I'm again left wondering under what circumstances you need a powerful laptop with a long battery.
not the slowest portable they can still force to run an OS?
Do you know what an OS is? The iPhone runs a modified OS X. There's Windows Mobile and Linux devices, too.
Very rarely will you find a portable device these days that doesn't have some kind of OS, even if it's something like tron.
If you meant "fully functional desktop OS", nope, still not accurate. While people have put XP on the eee, its default configuration is a pretty heavily customized Linux, in a mode which minimizes the RAM used just to show you a desktop environment, giving you more for actual apps. But if your standard is "able to show me windows and a Firefox browser", I've still got you beat -- even old Jornada handhelds can do that (slowly), by compiling a full desktop Firefox for ARM.
I don't think that word means what you think it means.
I think in this context, "wrong" is partly talking about going against popular wisdom, but is also largely a moral judgment. If you kill people for a living, you may be successful, but it's also wrong. A case could be made that the way Steve Jobs manages, and the corporate policies of Apple, are ethically wrong, but work anyway.
Ever actually used MS Office for something non-trivial. It beats the pants off Openoffice.
Depends what features you want.
I want to be able to read my documents in 100 years. ODF can do this. Office? Maybe -- but for the next 15 years, there might be patent issues, and it's certainly not as easy.
I want to be able to programmatically convert and scrape documents. Also easier to do in ODF -- almost trivial, actually.
There's also a decent set of features which were supported first in OpenOffice, before they were in MS Office, if they ever made it to MS Office at all. Suggested word completions as you type, save as PDF, and so on...
I want to run my presentations on any computer. No, any laptop that happens to be sitting around somewhere. It's possible to have a portable OpenOffice on a USB stick for Windows, a NeoOffice installer for OS X (not sure if there's an actually-portable version), and even turn that USB stick into a bootable Linux distro. And I can save it in PowerPoint format, in case that ends up being faster. With MS Office, if the only computer available doesn't have PowerPoint, there's not a lot you can do. Maybe you can get a free PowerPoint viewer, but then what do you do for last-minute changes?
These may be different features than the ones you care about, or even the ones most people care about, but it's easy to see why someone would call it better. (Or worse.)
I've been crushed by bugs (can only install a user package as root)
I thought that was by design? I'm not sure what you mean by "user package", though.
Also, apt/dpkg has been better for awhile, particularly the distributions built around it. I very rarely actually download a deb -- more often, I add a repository. I can't remember the last time a dependency hasn't been resolved.
As for click-and-drag, that doesn't automatically resolve dependencies, and it isn't always that simple (remember.mpkg?), especially uninstallation.
Strictly speaking, the only real comparison you could make would be to Windows Update or Steam, and both of these are missing basic features when compared to a real package manager.
Other than leaking source code onto the Internet, I don't really see what problems this could cause. I work at a small company with a similar philosophy -- the company buys your hardware, and certain software if you need it, but you can use whatever you want so long as you're not fighting with it on the clock.
But think about it: Spam botnets can be blocked by killing port 25 outbound. Data loss can be managed by the fact that everything's on version control, which is backed up. Traditional spyware and viruses will at worst take a machine down, at which point, it's the responsibility of whoever owns that machine to fix it -- or maybe they try to spread over the local network, at which point, staying patched and/or running a personal firewall will pretty much stop it.
The only real danger would be if we got big enough to be a target for deliberate attacks, and someone stole our source code. Google is arguably this big, but I've never heard of a leak from them. TFA does mention a possible strategy:
We have antivirus and antispyware running on people's machines, but we also have those things on our mail server. We have programs in our infrastructure to watch for strange behavior. This means I don't have to worry about the endpoint as much.
So what mistake could one employee make to ruin it for everyone?
Putting any more information in the SQL database than absolutely necessary is putting it in the wrong place. That logic belongs in the model, as ActiveRecord has done.
Except the database was built for concurrency, and ActiveRecord wasn't. Example: validates_uniqueness_of is a nice thing to have, but it is NOT a substitute for a unique index in the database.
Putting that kind of information in the database helps, because it means I can be scalable without trying; the database has (mostly) solved the concurrency issues for me, and multiple Rails processes don't have to know about each other, or even be on the same machine. There's no reason the model couldn't do all that, but ActiveRecord doesn't, and it means you do have to reinvent the wheel on that part.
From a quick glance, I can't figure out exactly what thrudb is designed to do, or what ActiveDocument will provide in this respect.
I would argue that most C++ features are actually pretty uninteresting, once you know the rest of these. All they really do is add to the bloat -- sometimes hurting the syntax because of it. It's been awhile, but I remember a point at which you have to put a space between closing angle brackets in nested template definitions, because together, they'd be a bitwise shift operator.
So, if you have to work in C++, absolutely learn all the features. I don't think they contain quite the same kind of useful lessons as the other languages I mentioned, though -- when I program JavaScript, I'm still thinking in Ruby, and my code is better for it.
its primary data structure, the Object (an associative array, basically) coerces all keys into strings. This means that if you try to use another object as a key, it gets coerced into something like "[Object:0x12345678]"...
I guess I'm struggling to see when using something else as a key would be something you'd want to do.
First-class functions and methods? Yup, it's got that... with some *really weird* semantics when it comes to 'this'.
They're actually about what I'd expect, but maybe that's because I did so much JavaScript development.
Also, I learned how to use call() and apply(), and I'm missing these occasionally in Ruby -- it seems unnecessarily difficult to just hijack a method and apply it to a different object.
object.foo(); var f = object.foo; f();
See, by now, I intuitively know to do:
var f = function() { object.foo(); }
But maybe that's because I used to abuse the callback system so much. I loved writing constructs like this:
some_list.sort(function(x, y) { ... });
There's also this useful trick, for some of the other strangeness with 'this':
var that = this;
which allows the same value for 'that' to persist up through other closures. I'm not really sure there's a better way to do that.
var defines a local variable, right? No, it doesn't, it assigns a new value to the current object context.
Which is usually enough -- it's local to the function, and as I've just outlined, I use a ton of functions. When I want to define a scope just to define a scope:
(function() { ... })();
Not pretty -- there are actually quite a few things I find ugly about JavaScript syntax -- but I haven't really found it to be unambiguous in a long time.
The thing about optional semicolons is pretty horrible, too.
They're not optional with the interpreter I was developing against, so not so much of an issue.
I'd emphasise Smalltalk more. Smalltalk is a beautiful language. All the shiny new language features people are rediscovering today, Smalltalk had in 1980. Concurrency, dynamicism, polymorphism, extreme programming, closures... it had 'em all. And nobody noticed. It's a shame...
Yeah, it looked really cool, but lack of x86_64 support was kind of a deal-breaker for me.
I'd suggest erlang for its own sake -- a parallel programming model that doesn't suck as much as threads with locks.
C -- you think you know it, because you know C++, but you really don't. Also, if you're on Unix, you'll need it at some point.
JavaScript/EcmaScript -- has nothing to do with Java. Dynamic everything, closures, first-class functions -- most of the Lisp-y goodness, but you already know the C-like syntax.
Erlang -- pervasive message passing as a language construct.
Ruby -- beautiful syntactic sugar for most of the JavaScript/Lisp tricks you learned elsewhere. Nice for domain-specific languages, too.
Disclaimer: I don't actually know Smalltalk (Squeak won't run on my machine), Prolog, Verilog, or Scheme. I did learn Lisp, once upon a time.
Also: I think that while we do have languages that are good for specific tasks, every language I've tried is missing something I consider to be critical.
Sometimes I'm able to bring it in -- with JavaScript, I can almost emulate Ruby's iterators (each, collect, etc). But sometimes, it's something more pervasive -- for instance, while most languages support some kind of threads, they often allow supporting libraries to be written in such a way that they break when used in threads, and some of my favorite languages (Ruby, Python, Perl) don't support real OS threads actually running in parallel. (Python has a Global Interpreter Lock, and Ruby seems to be about to adopt the same, meaning that a single process of each won't be able to really take advantage of multicore/multiprocessor systems.)
Sometimes, these things are mutually exclusive -- how do you have a purely-functional, lazily-evaluated language, and also make it simple and imperative? But most of the ones I care about aren't -- there's no reason a language like Ruby couldn't be written to be fast, bytecode-compiled, and truly threaded. There's no reason a language like Erlang has to have non-variable variables and ass-ugly syntax.
Another possible response is, do some spying on that person. Follow them to the bathroom -- even better if it's the opposite sex. Or follow them home.
"I thought you had nothing to hide?"
Even if there wasn't the tendency to find evil where none exists -- and for an example of that, there's a particularly good episode of Battlestar Galactica I'd show them -- privacy is still a basic human right.
Where it gets really dangerous is when you still divide people into "bad people" and "good people", even though you start to realize that good people can do bad things, and vice versa.
At which point, you believe that you can be a "good person" even if you do bad things -- and thus, you should be exempt from all of the things done to "bad people". At which point, you're not above using bad tactics to keep yourself looking like a good person...
And of course, good people are allowed to do bad things openly, if they do them to bad people.
I would imagine that most politicians fall into this category, which is why it's so dangerous.
I don't know if you're trolling, or if you actually believe that.
The problem is that child molesters, killers, thieves, and so on, are going to be the ones who find places which don't have the cameras installed yet -- or maybe they're the ones who have a buddy who's responsible for monitoring the cameras. Meanwhile, the rest of us lose a basic human right to privacy -- the government gets to watch every "move" you make, so to speak.
Maybe they should put cameras in the bedroom, too? I'm sure they'll just be checking that your date is 18, and not uploading the sex tape onto the Internet...
Just because you don't care about your own privacy doesn't make it any less of a basic human right -- in fact, it's in the Universal Declaration of Human Rights. You'd better have a damned good reason to take it away, and "it might stop some child molesters -- maybe" isn't a good enough reason.
Now, let's talk about that Virginia Tech dorm. Do you honestly believe there'd be someone watching every single dorm, all the time? If so, isn't that a bit creepy, too? If not, someone's going to slip through -- they'll "accidentally" bump the camera offline, or throw something over it, and no one will notice until the next day, when a bunch of people are dead.
it's entirely possible more people believe the government is more secretive--but they simply don't care.
I'm not even sure "more secretive" has anything to do with domestic spying. It could be simply that most people don't much care that the government does secret things, but still don't want the government to spy on them.
You could argue that the two go together, in that if the government wasn't secretive, they couldn't spy on us. But think about your neighbor -- you probably really don't care what they do all day... but I bet you still don't want them staring at your windows all day.
The root of the problem here is that using an RDBMS for most web applications is a hack, no matter what language or framework you are using.
What alternative would you suggest?
But then came along the DBAs who failed to see why SQL is the wrong tool for the job and expected ActiveRecord to support every esoteric feature the RDBMS has to offer.
I like to think that the plugins I mention are a good idea regardless. For example, "validates_uniqueness_of" is never going to be thread-safe without taking a pretty massive performance hit (locking an entire table on every save). It's the perfect candidate for something which should be enforced at the database level (or storage level), so that multiple Rails processes won't trip over each other. But as soon as I'm creating a unique index, I certainly like not-repeating-myself by having the "validates_uniqueness_of" generated from that index.
But I think it's unfortunate how many people missed the point on why features such as foreign keys are not described in the database as far as ActiveRecord is concerned.
The only reason I see is that ActiveRecord supports multi-table polymorphism, and I honestly don't know how I would go about creating a foreign key relationship for that. Even single table inheritance would seem to be a problem.
I do know what you mean by "hitting the nail with the handle of a screwdriver" -- it's painful to see all those VARCHARS used to specify the class of a particular row or association. But I simply don't know of a better alternative, other than a SQL database extended to support AR-specific features. That is, I see AR wanting more features, not less, than a standard SQL database. (Why shouldn't foreign keys be supported, other than that they aren't flexible enough?)
Oh, and there is at least one thing that still pisses me off about ActiveRecord, mostly because it has been known about (and not resolved) for so long -- forget stored procedures, what about simple prepared statements? Especially when ActiveRecord does support syntax that looks like it was meant for a prepared statement, but is really doing its own escaping under the hood? I understand AR was meant for things like MySQL and SQLite, but it's still taking a performance hit for no good reason on things like PostgreSQL and Oracle.
On the bright side, I foresee Rails moving completely away from ActiveRecord as the default data access layer in the not so distant future.
I'm not too hopeful. The current default is SQLite.
Slashdot Mirror
More than that. Before it's even asked, it is broadcasting that it will give permission to anyone who asks.
It's not just "leaving the door unlocked" -- this is more equivalent to leaving the door unlocked, and posting a sign outside with big flashing lights that says "Unlocked door here!" -- and then going down to your local public access television and doing a show called "Did you know my door is unlocked? Here's my address! I'll be happy to let you in!"
And as someone else points out, part of the problem is that those of us who genuinely did intend for the access point to be open to all comers no longer have a technological way of advertising that.
How it seems to work:
Actual "ramdisk" -- that is, like /dev/rd -- that is, appears as a block device. You can run whatever filesystem you want on it, but it's still serializing and writing out to... well, RAM, in this case. No sane way for the kernel to free space on that "disk" that's not actually used.
How I wish it worked:
No Linux that I know of has used an actual ramdisk in forever. Instead, we use tmpfs -- a filesystem which actually grows or shrinks to our needs, up to an optional configurable maximum size. It'll use swap if available/needed. It's basically a RAM filesystem, instead of a RAM disk.
Even initrds are dead now -- we use initramfs. Basically, instead of the kernel booting and reading a ramdisk image directly to /dev/rd0, it instead boots and unpacks a cpio archive (like a tarball, but different/better/worse) into a tmpfs filesystem, and uses that.
So, how I would like this to work is, use a tmpfs filesystem -- as I suspect it will be faster, and in any case simpler, than a ramdisk -- and back it to a real filesystem on-disk. The only challenge here is that it's not as deterministic -- it would be more like a cp than a dd.
An even better (crazier) idea:
Use a filesystem like XFS or Reiser4 -- something which delays allocation until a flush. In either case, it would take a bit of tweaking -- you want to make sure no writes, or fsyncs, block while writing to disk, so long as the power is on -- but you'll hopefully already be caching an obscene amount anyway, so reads will be fast.
In this case, forcing everything out to disk could be as simple as "mount / -o remount,sync" -- or something similar -- forcing an immediate sync, and all future writes to be synchronous.
Conclusion:
Either of the two ideas I suggested should work, and could perform better than a traditional ramdisk. If it is, in fact, a simple disk-backed ramdisk (not ram filesystem), then it's both not as flexible (what if your app suddenly wants 50 gigs of RAM in application space?) and a bit of a hack -- probably a hack around traditional disk-backed filesystems not being able to take advantage of so much RAM by themselves.
In fact, glancing back at TFA, it seems there are some inherent reliability concerns, too:
Now, true, this should never happen, but in the event it does, the inherent problem here is that the ramdisk doesn't know anything about the filesystem, and so it doesn't know in what order it should be writing stuff to disk. Ext3 journaling makes NO sense for a ramdisk when the ramdisk itself knows nothing about the journal -- the journal is just going to slow down the RAM-based operation. Compare this to a sync call to XFS -- individual files might be corrupted, but all the writes will be journaled in some way, so at least the filesystem structure will be intact.
This gets even better with something like Reiser4's (vaporware) transaction API. If the application can define a transaction at the filesystem level, then this consistent-dump-to-disk will happen at the application level, too. Which means that while it would certainly suck to have a UPS fail, it wouldn't be much worse than the same happening to a non-ramdisk device, at least as far as consistency goes. (Some data will be lost, no way around that, but at least this way, some data will be fine.)
This story reminds me of yesterday's WTF...
Government, and social pressures, and...
Wait a second, isn't this horribly offtopic? Not all dangers on the road are created by stupidity. Even if there was no one else around, no weather conditions, perfectly clear road, etc, you're still quite literally taking your life into your hands. The faster you're going, the less of a mistake (or deliberate twitch of the wheel, if you're feeling suicidal) is required to end your life.
Certainly, it'd still be a lot safer without these other people, but I don't think that was the point.
It's caused by you actually driving, rather than walking, biking, flying, grabbing a train, etc.
Not that I expect you to stop driving. I'm just pointing out that you don't actually have a need to drive. Therefore, you're making a choice, consciously or unconsciously, to drive or not to drive. If you choose to drive, knowing the roads are going to be dangerous -- whether caused by idiots or not -- you still chose to take that risk, rather than avoid it. And you probably chose it for the convenience it would bring.
It's a different context than what you dug up -- certainly, we shouldn't passively accept that other people will be assholes on the road. In fact, when I find people tailgating me, I like to hit the brakes. Either they actually do slam into me, in which case, it's their fault -- I can claim to have seen a deer or something -- or it at least demonstrates to them the danger of being too close, especially being too close to me. Either way, they're off my ass.
That seems like a very odd mistake to make -- off the top of my head, I could probably guess array.count, or array.size, array.length, etc. I probably wouldn't know about array.lastIndex, let alone array.lastIndex.indexNum.
Or guns.
It's still an ambiguous case, and one that a newbie is fairly likely to hit. There are languages that have none of these problems (lisp), and languages that have far fewer of these problems (Ruby).
The closest I see to that with Ruby (or Perl) is the fact that both have a lot of syntax which is optional in cases where it can be implied. And most of the time, if you hit a case like this, the resolution is obvious -- just add more parentheses. The solution to issues like that template syntax thing is simply not as obvious.
I see it as powerful the way C is powerful -- Turing-complete, runs fast, and you can build other languages in it, if needed.
Yes, there are interesting things you can do with the object-orientedness. But they are not half as interesting as what is possible in newer languages, IMNSHO. A little basic reflection goes a long way, among other things...
I also like open classes/modules, closures, mixins, and garbage collection, and I don't like such a strict static type system, pointers as integers, the operator overloading used for IO (seriously, std::cout
I mean, I don't like templates in general. I'm hooked on Ruby's duck typing.
I am sure that a lot of these can be worked around or tacked on in various ways, but why bother, when there are already better languages out there?
I suppose we bother because of performance (sometimes) and legacy projects. And maybe Windows drivers. But I can't really think of any other good reasons.
That seems a bit absurd. Aside from code being reviewed on commit, or periodically, do you think they'd be able to actually deploy it to gmail.com without it being caught first? I really hope they're testing things separately and internally before making them live, even if it is a "beta" product.
Seems to me they could just as easily turn around and sue you for abuse of company property. I'm sure you signed an agreement with what you're legally allowed to do (or not do) with company equipment. And if it was your own equipment, it's even less their problem.
Well, they did mention places you could go to grab software. I imagine just about any software you need to do your work, you can get through official channels. Thus, any software that's not kosher could fall back on "Well, we provided all this legitimate stuff for the employee, it's not our fault they did something different."
Disclaimer: I don't actually know how this would work. I am not a lawyer. I don't even play one on TV.
Alternate disclaimer: We were talking about security, not licenses, right? Is this offtopic?
Show me how.
And traditional viruses/spyware won't do that.
The trouble is, modern OSes are reasonably secure at this point, and you can bet the external-facing IPs are going to be locked down. Same with internal services -- some random developer's desktop might be open, but the service is going to be secure. So what you're talking about is someone actively making a "hacking" attempt at something that, to my mind, looks pretty much impenetrable.
The only other option is something more insidious -- set up a website which exploits some browser flaw, then hope someone at Google sees it. Or sit around a wifi hotspot, praying that someone logs on with a laptop that's vulnerable, infect it, set it to phone home, then pray it is actually able to phone home, and that Google doesn't take a peek at exactly where it's phoning home to.
And a successful variation of this is still just going to give you the one insecure machine. It's not going to give you the entire network. It's probably got less of a chance of doing that than if they were extremely anal-retentive in their security policy (and refused local-admin rights, etc), because it's going to be a heterogenious network.
But then, you did just provide the perfect counterargument: The first hacker to take down their network, either internal or external facing, would be infamous. Therefore, people are trying. It's not working. Therefore, whatever Google is doing for security is working.
No, but the bit about Netflix does. Netflix physical DVD rentals rely on no more DRM than CSS, for which the crack takes up less space than this post. They basically rely on people not knowing how to rip and burn DVDs -- except there are one-click programs to do exactly that.
The reason you keep your netflix subscription is, you want to have something new to watch. (Or something old that you haven't seen yet.) And that's why you'd keep a subscription to any DRM-free service -- because they'd bring you new content. If they stopped doing that, you could cancel your subscription.
Except it really isn't.
It'd be tricky to do, but it could certainly work, and it would make money. The only downside is, no one would buy individual songs or albums ever again, so it'd be difficult to get the producers sold on such a model. Right now, DRM'd stuff is seen as somewhat safer, as there's always that looming threat of losing your entire collection if you stop paying for it -- which means that either revenue keeps coming in, or people lose the music and have to start buying CDs again.
I can.
To beat piracy, you must provide better service, not worse. As long as there are Flac torrents out there, I will never buy DRM'd AACs. But when I do find a band I like selling Flac downloads, I buy them.
Understand, DVDs almost do not count anymore, as CSS has been braken everywhere for years, and every new scheme is more desperate and futile than the last -- yet NetFlix still makes money. If Apple provided this service without the DRM, they would still make money, so long as there was new and interesting music.
Well, as the other article shows, Steve Jobs habitually lies about this kind of thing. Probably half of Apple, never mind the rest of the world, assumed that Apple was going to stay the course with PowerPC, right up until the Intel macs were released. Steve had to know about this, yet he let the Apple.com site continue to spew BS about the G5's "intel-crushing performance"... Again, right up to (and maybe a bit past) the point at which they went Intel.
Because it's cheap and tiny. And because no one else has made a fully functional computer that is this cheap and this small -- generally, it's been just the opposite, where smaller costs more.
You speak as if an X2 is slow?
And...
Why? Seriously, why?
What is it that you need to do on the train, bus, plane, in a car, in the park, etc, that requires a dual-core processor? Under what circumstances do you need to do something that requires that much power, and you can't simply go back to a desktop somewhere? Or even remote to one?
They are. Or didn't you notice?
That makes even less sense.
You want something extremely powerful, so that it can use less battery life? WTF?
Here's a hint: All the computers I currently own tend to clock themselves back to 1 ghz, in order to save power. Why is it that you think a faster processor would give you more battery life? A newer one, sure, but not a faster one.
It might also be worth investigating how big a battery you can buy for the eee, or how cheap they are. It's not exactly pleasant, but you can certainly shut down, swap batteries, and boot again -- assuming it doesn't have a couple minutes of onboard battery (probably not, but maybe). Or give it some extra storage and figure out how to make it hibernate while you do that. Or find an outlet and plug in -- I'm again left wondering under what circumstances you need a powerful laptop with a long battery.
Do you know what an OS is? The iPhone runs a modified OS X. There's Windows Mobile and Linux devices, too.
Very rarely will you find a portable device these days that doesn't have some kind of OS, even if it's something like tron.
If you meant "fully functional desktop OS", nope, still not accurate. While people have put XP on the eee, its default configuration is a pretty heavily customized Linux, in a mode which minimizes the RAM used just to show you a desktop environment, giving you more for actual apps. But if your standard is "able to show me windows and a Firefox browser", I've still got you beat -- even old Jornada handhelds can do that (slowly), by compiling a full desktop Firefox for ARM.
I don't think that word means what you think it means.
I think in this context, "wrong" is partly talking about going against popular wisdom, but is also largely a moral judgment. If you kill people for a living, you may be successful, but it's also wrong. A case could be made that the way Steve Jobs manages, and the corporate policies of Apple, are ethically wrong, but work anyway.
Depends what features you want.
I want to be able to read my documents in 100 years. ODF can do this. Office? Maybe -- but for the next 15 years, there might be patent issues, and it's certainly not as easy.
I want to be able to programmatically convert and scrape documents. Also easier to do in ODF -- almost trivial, actually.
There's also a decent set of features which were supported first in OpenOffice, before they were in MS Office, if they ever made it to MS Office at all. Suggested word completions as you type, save as PDF, and so on...
I want to run my presentations on any computer. No, any laptop that happens to be sitting around somewhere. It's possible to have a portable OpenOffice on a USB stick for Windows, a NeoOffice installer for OS X (not sure if there's an actually-portable version), and even turn that USB stick into a bootable Linux distro. And I can save it in PowerPoint format, in case that ends up being faster. With MS Office, if the only computer available doesn't have PowerPoint, there's not a lot you can do. Maybe you can get a free PowerPoint viewer, but then what do you do for last-minute changes?
These may be different features than the ones you care about, or even the ones most people care about, but it's easy to see why someone would call it better. (Or worse.)
I thought that was by design? I'm not sure what you mean by "user package", though.
Also, apt/dpkg has been better for awhile, particularly the distributions built around it. I very rarely actually download a deb -- more often, I add a repository. I can't remember the last time a dependency hasn't been resolved.
As for click-and-drag, that doesn't automatically resolve dependencies, and it isn't always that simple (remember .mpkg?), especially uninstallation.
Strictly speaking, the only real comparison you could make would be to Windows Update or Steam, and both of these are missing basic features when compared to a real package manager.
I'm not really sure how that works.
Other than leaking source code onto the Internet, I don't really see what problems this could cause. I work at a small company with a similar philosophy -- the company buys your hardware, and certain software if you need it, but you can use whatever you want so long as you're not fighting with it on the clock.
But think about it: Spam botnets can be blocked by killing port 25 outbound. Data loss can be managed by the fact that everything's on version control, which is backed up. Traditional spyware and viruses will at worst take a machine down, at which point, it's the responsibility of whoever owns that machine to fix it -- or maybe they try to spread over the local network, at which point, staying patched and/or running a personal firewall will pretty much stop it.
The only real danger would be if we got big enough to be a target for deliberate attacks, and someone stole our source code. Google is arguably this big, but I've never heard of a leak from them. TFA does mention a possible strategy:
So what mistake could one employee make to ruin it for everyone?
Except the database was built for concurrency, and ActiveRecord wasn't. Example: validates_uniqueness_of is a nice thing to have, but it is NOT a substitute for a unique index in the database.
Putting that kind of information in the database helps, because it means I can be scalable without trying; the database has (mostly) solved the concurrency issues for me, and multiple Rails processes don't have to know about each other, or even be on the same machine. There's no reason the model couldn't do all that, but ActiveRecord doesn't, and it means you do have to reinvent the wheel on that part.
From a quick glance, I can't figure out exactly what thrudb is designed to do, or what ActiveDocument will provide in this respect.
I would argue that most C++ features are actually pretty uninteresting, once you know the rest of these. All they really do is add to the bloat -- sometimes hurting the syntax because of it. It's been awhile, but I remember a point at which you have to put a space between closing angle brackets in nested template definitions, because together, they'd be a bitwise shift operator.
So, if you have to work in C++, absolutely learn all the features. I don't think they contain quite the same kind of useful lessons as the other languages I mentioned, though -- when I program JavaScript, I'm still thinking in Ruby, and my code is better for it.
I guess I'm struggling to see when using something else as a key would be something you'd want to do.
They're actually about what I'd expect, but maybe that's because I did so much JavaScript development.
Also, I learned how to use call() and apply(), and I'm missing these occasionally in Ruby -- it seems unnecessarily difficult to just hijack a method and apply it to a different object.
See, by now, I intuitively know to do:
But maybe that's because I used to abuse the callback system so much. I loved writing constructs like this:
There's also this useful trick, for some of the other strangeness with 'this':
which allows the same value for 'that' to persist up through other closures. I'm not really sure there's a better way to do that.
Which is usually enough -- it's local to the function, and as I've just outlined, I use a ton of functions. When I want to define a scope just to define a scope:
Not pretty -- there are actually quite a few things I find ugly about JavaScript syntax -- but I haven't really found it to be unambiguous in a long time.
They're not optional with the interpreter I was developing against, so not so much of an issue.
Yeah, it looked really cool, but lack of x86_64 support was kind of a deal-breaker for me.
I will look at Io again...
I'd suggest erlang for its own sake -- a parallel programming model that doesn't suck as much as threads with locks.
Disclaimer: I don't actually know Smalltalk (Squeak won't run on my machine), Prolog, Verilog, or Scheme. I did learn Lisp, once upon a time.
Also: I think that while we do have languages that are good for specific tasks, every language I've tried is missing something I consider to be critical.
Sometimes I'm able to bring it in -- with JavaScript, I can almost emulate Ruby's iterators (each, collect, etc). But sometimes, it's something more pervasive -- for instance, while most languages support some kind of threads, they often allow supporting libraries to be written in such a way that they break when used in threads, and some of my favorite languages (Ruby, Python, Perl) don't support real OS threads actually running in parallel. (Python has a Global Interpreter Lock, and Ruby seems to be about to adopt the same, meaning that a single process of each won't be able to really take advantage of multicore/multiprocessor systems.)
Sometimes, these things are mutually exclusive -- how do you have a purely-functional, lazily-evaluated language, and also make it simple and imperative? But most of the ones I care about aren't -- there's no reason a language like Ruby couldn't be written to be fast, bytecode-compiled, and truly threaded. There's no reason a language like Erlang has to have non-variable variables and ass-ugly syntax.
Another possible response is, do some spying on that person. Follow them to the bathroom -- even better if it's the opposite sex. Or follow them home.
"I thought you had nothing to hide?"
Even if there wasn't the tendency to find evil where none exists -- and for an example of that, there's a particularly good episode of Battlestar Galactica I'd show them -- privacy is still a basic human right.
Where it gets really dangerous is when you still divide people into "bad people" and "good people", even though you start to realize that good people can do bad things, and vice versa.
At which point, you believe that you can be a "good person" even if you do bad things -- and thus, you should be exempt from all of the things done to "bad people". At which point, you're not above using bad tactics to keep yourself looking like a good person...
And of course, good people are allowed to do bad things openly, if they do them to bad people.
I would imagine that most politicians fall into this category, which is why it's so dangerous.
I don't know if you're trolling, or if you actually believe that.
The problem is that child molesters, killers, thieves, and so on, are going to be the ones who find places which don't have the cameras installed yet -- or maybe they're the ones who have a buddy who's responsible for monitoring the cameras. Meanwhile, the rest of us lose a basic human right to privacy -- the government gets to watch every "move" you make, so to speak.
Maybe they should put cameras in the bedroom, too? I'm sure they'll just be checking that your date is 18, and not uploading the sex tape onto the Internet...
Just because you don't care about your own privacy doesn't make it any less of a basic human right -- in fact, it's in the Universal Declaration of Human Rights. You'd better have a damned good reason to take it away, and "it might stop some child molesters -- maybe" isn't a good enough reason.
Now, let's talk about that Virginia Tech dorm. Do you honestly believe there'd be someone watching every single dorm, all the time? If so, isn't that a bit creepy, too? If not, someone's going to slip through -- they'll "accidentally" bump the camera offline, or throw something over it, and no one will notice until the next day, when a bunch of people are dead.
I'm not even sure "more secretive" has anything to do with domestic spying. It could be simply that most people don't much care that the government does secret things, but still don't want the government to spy on them.
You could argue that the two go together, in that if the government wasn't secretive, they couldn't spy on us. But think about your neighbor -- you probably really don't care what they do all day... but I bet you still don't want them staring at your windows all day.
What alternative would you suggest?
I like to think that the plugins I mention are a good idea regardless. For example, "validates_uniqueness_of" is never going to be thread-safe without taking a pretty massive performance hit (locking an entire table on every save). It's the perfect candidate for something which should be enforced at the database level (or storage level), so that multiple Rails processes won't trip over each other. But as soon as I'm creating a unique index, I certainly like not-repeating-myself by having the "validates_uniqueness_of" generated from that index.
The only reason I see is that ActiveRecord supports multi-table polymorphism, and I honestly don't know how I would go about creating a foreign key relationship for that. Even single table inheritance would seem to be a problem.
I do know what you mean by "hitting the nail with the handle of a screwdriver" -- it's painful to see all those VARCHARS used to specify the class of a particular row or association. But I simply don't know of a better alternative, other than a SQL database extended to support AR-specific features. That is, I see AR wanting more features, not less, than a standard SQL database. (Why shouldn't foreign keys be supported, other than that they aren't flexible enough?)
Oh, and there is at least one thing that still pisses me off about ActiveRecord, mostly because it has been known about (and not resolved) for so long -- forget stored procedures, what about simple prepared statements? Especially when ActiveRecord does support syntax that looks like it was meant for a prepared statement, but is really doing its own escaping under the hood? I understand AR was meant for things like MySQL and SQLite, but it's still taking a performance hit for no good reason on things like PostgreSQL and Oracle.
I'm not too hopeful. The current default is SQLite.