Turns out that when you get it to a usable state, and stop screwing with it, Gentoo works a lot like Ubuntu.
I think Ubuntu provides more, but even assuming that's the case, I'll take Ubuntu any day for the simple reason that precompiled binaries install faster than source code.
Sure, you can use binary tarballs on Gentoo, and you can speed things up with a shared binary cache, and with distcc and ccache (or whatever you kids are using nowdays), but that falls under "screwing with it" -- and if it brings me to something which works as well as Ubuntu, what was the point?
I'm glad I used Gentoo -- it gave me a much deeper understanding of how the OS is put together. But I'm equally glad I no longer use Gentoo.
If I open you unlocked door, and say "Hi" to you on the couch, I'm trespassing. If I open your door, walk in and steal your remote, I'm breaking & entering.
Which is it, then, if you see someone naked through her open window from the street? Or if you take pictures?
I think that's a better analogy -- it's some private information, but ultimately, nothing was taken, and nothing was even broken into. All that happened is some publicly available information was accessed, and possibly copied -- but it shouldn't have been public in the first place.
Sure, you shouldn't have taken pictures, and you should have turned away. But she could've just closed her blinds.
Unfortunately, there's no good way to tell her about it...
My own counterpoint: Flash itself requires hiring an engineer, you just don't know it yet.
The standards are open. The problem is not the proprietary nature of protocols or applications, but that the standards are not obeyed.
There is additionally the problem that proprietary standards (and implementations) tend to evolve faster than open standards, at least on the Internet.
It should travel with all the things that it needs, and you donâ(TM)t need anything more complex than something like X Windows.
This quote is ridiculously out of touch -- X Windows is itself a horribly bloated standard. The difference is, HTML is still mostly useful for its original purpose -- you can still build semantic HTML, style it with pure CSS, and use it to deliver hypertext.
You can't really use X for its original purpose -- I can't reliably access another machine, run an X app there, and have it display on my local X server reliably. Even if it's running the same version of xlib -- if they're different versions, it's going to be even buggier.
You neednâ(TM)t do more than attempt to watch a streaming video on a busy office LAN or oversubscribed DSL circuit to understand that even the best-served markets for Internet connectivity are struggling to keep up with demand for networked content.
If it's the same video, you can stick a caching proxy in front of that LAN...
But really, the death of the Internet has been predicted for ages. Look up Metcalfe's prediction of the "gigaflood" being the end of the Internet...
Eventually, we can just throw bandwidth at the problem. In fact, we can right now -- the amount of bandwidth to send a book, in text format (or even a PDF), is completely irrelevant. It's only when you want to do what isn't feasible yet (stream an HD movie) that you need hacks like CDNs -- eventually, the sheer amount of bandwidth will solve the problem.
We know too that near-universal deployment of technologies with inadequate security and trust models, like SMTP, can mean millions if not billions lost to electronic crime, defensive measures, and reduced productivity.
"Defensive measures" -- Bayesian filters are trivially easy. Captchas are only a problem if you're giving away free accounts, which is completely unrelated to SMTP.
But more importantly, no one has come up with a solution to Spam, SMTP or not, which also provides all the functionality of SMTP.
I don't believe Rails is more crash-prone or scaling-challenged than other platforms. Twitter is certainly not the only site to fall over frequently (look at Myspace). And Rails has been used for much more reliable apps than Twitter.
Anyone can build a shitty app on a good architecture.
All they're doing is making an example out of him.
Wrong example. Unless the email was actually directly threatening something -- and without further details, we just don't know -- the example they're setting is, "Look what happens when you do the right thing! Don't ever tell us when our security is fucked up -- just quietly exploit it, and make sure we don't notice."
Opening a closed but not locked door and entering a building without permission is still against the law. It is called breaking and entering.
IANAL, and I'm just guessing, but wouldn't that be tresspassing? I mean, if you're breaking and entering, I would assume that requires the breaking of something, right?
He has been charged with a crime for something he did, namely "computer trespass" for accessing a system without permission.
There you go.
I would also like to know more about the circumstances. I don't think curiosity should be a crime, and I do think there should be a much more rigid definition of what constitutes "unauthorized access" -- in particular, I think the burden should be to show that the access was, in fact, unauthorized, rather than requiring everyone to keep a clear record of authorization from every site we've ever accessed.
Having read TFA, it looks very much like, by any technological definition, he was authorized. There would have to be pretty clear indications that he wasn't supposed to be there.
And even if he was entirely at fault, this is also entirely the wrong way to go about it. The lesson to be learned here, from any other student who's paying attention, is simply to not tell anyone what you know.
I'm told by/.'s resident graphics devs that, essentially, Dx9 is to them what MacOS X is to power users, and that opengl was clunky, and falling behind.
Some of that is true, and most of it is FUD. Ultimately, it boils down to DirectX giving you more out of the box (in other words, from people who don't know about SDL), and being a more convenient API. Which isn't bad, but if you're developing at the graphics layer, I really hope you're building a better API on top of it -- neither DirectX or GL are a very good game API, and that's what we need.
In terms of raw performance and functionality, neither holds an edge over the other for very long. Having read Carmack's rant, I suspect GL is still faster, but not by enough for anyone to care.
For what it's worth: OS X is one option. I still use Linux, and much prefer it to OS X.
It's just the thin-client model being sold under yet another name.
That or timesharing. Or clustering. Or all of the above.
I'm getting a bit tired of people just throwing a buzzword of last week to try to explain the buzzword of this week...
It's a bit like claiming texting is just email being sold under yet another name. I've been known to do this, to make a point about the price -- but even when the analogy fits, the circumstances are different, and that does matter.
In this case, the thin-client model is often bandwidth-heavy and requires special client software. These "cloud" services (yuck) are actually pretty bandwidth-efficient, and require nothing more than a decent web browser.
If you think about it for a second, they are bandwidth-efficient because they are NOT a thin-client model. The browser is a limited client, but you can still run Javascript, which is now fast enough to rival most other scripting languages.
Combine it with the timesharing/cluster model, and it's going to be more reliable, too.
There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.
That was actually my first thought. What does this do that STOMP doesn't?
Leave it to Microsoft to pick the one I've never heard of...
It would be cool to be able to do a "Speed up my computer" boot where it loads the modules, and then compiles a kernel with the modules for the hardware it finds compiled into it.
This would be both dishonest (it's not just "speeding it up", it's also binding that install to that particular hardware configuration) and pointless (loading modules is simply not a performance bottleneck).
OR, how about loading modules when you actually need them..?
Tricky to get right, and also not necessarily what you want. When your computer goes to suspend or hibernate, you pretty much want every driver loaded, so you can tell it to suspend itself.
There's also the problem where not everything can be triggered that way. Even if the software allowed it (which it doesn't, always), there's the stuff you want to be triggered from outside that computer. Trivial example: Bluetooth. I use a Bluetooth mouse, and I want it to just work when I tell it to connect. I shouldn't have to go type, or worse, click something, to get the bluetooth stuff loaded.
And this goes for daemons, too. When you go to listen to something, and it returns that there's no module loaded for sound, how about loading the module then, and then starting the alsa daemon.
Same applies -- with Bluetooth, you need that daemon running.
Some of this is done -- on KDE3, the arts daemon is only started when something needs it, and is stopped when it's idle for 30 seconds. But some of it is equally pointless.
Now, sure, for lower end machines, I wouldn't use a full Ubuntu. I'd use something stripped down -- either xubuntu, or ubuntu-minimal/server plus fluxbox. But I think the focus has rightly been how Ubuntu works on newer hardware -- that is, after all, the future.
Turning point for me was realizing that I was compiling more and more in, just in case I needed it, because rebuilding world just to enable that new USE flag was getting kind of old.
In other words, I was using it like Ubuntu. The only advantage I had was I would compile for -march=i686, and other optimizations which produce binaries which only work on recent CPUs (the '686' class) -- whereas Ubuntu was -mtune=i686, if I remember, so it was possible to run on a 486, but would run best on a 686.
And, hey, there were other things I would turn on that were Athlon XP specific, and so on... then I realized that, on amd64, the optimizations were basically exactly the same -- merely compiling for x86_64 gave me all the benefits anyway. At which point, what the hell -- Ubuntu would necessarily be at least as optimized as my Gentoo.
And, more recently, I've realized that since switching to Ubuntu, I spend much more time actually using the OS, rather than tweaking it. Despite having it already much more customized than any version of Windows ever was, I still don't spend as much time tweaking it as it takes to maintain Windows, let alone Gentoo.
If your boss asks you to do something morally questionable, tell him you can't and take the consequences.
Depends how morally questionable. What's the impact?
Your example is borderline Godwin:
So wait, when someone asks you to invade Iraq and kill anywhere between 500.000 and 1.000.000 natives your answer would be "I'll e-mail you that this is a rather bad idea, but if you clarify the request, I'll do it"?
We're not talking about killing hundreds of thousands of people. We're talking about scraping a fucking website. At the end of the day, worst case, this starts costing said website some money, and they either sue your company (and your CYA will protect you), or they'll start blocking you, or they'll feed you bad data.
In either of the above cases, you've cost someone some money -- not hundreds of thousands of lives, but some increased bandwidth bills and some time -- and you've also taught your boss a lesson he'll never forget.
Of course, if you're going to be idealistic about it, why would anyone be working for this tool in the first place? If you can answer that question, you might also be able to answer why someone might want to continue working with this tool.
I vaguely remembered Steam, and I Googled for it, but all I found were references to the Penny Arcade strips themselves being available on Steam, which seems like a retarded idea. (Why would you want them via Steam, rather than via Firefox?)
I'll take your word for it. Irrelevant to me, as I bought it for Linux.
CGI days (only technical requirement is standard input and output) are long gone.
Well, not really. It still works. Your biggest complaint:
You gonna end up with huge performance problems unless you would use something more modern and advanced than trivial piping.
That is a vertical scaling concern. If vertical scaling is that important to you, consider using C, instead.
Not that it's unimportant. I'm just saying -- if all we had was CGI, there's no reason we couldn't still throw hardware at the problem.
No, I was talking about things like FastCGI, or even more relevantly, in-application webservers. It turns out, talking HTTP really isn't that hard. Ruby has, by my count, six separate in-application webservers supporting the common Rack API.
Throw a load balancer like nginx in front of them, and what do you need Apache for? Other than old apps which were tied too closely to it -- some mod_php (though those mostly tend to work with php as fcgi), and especially some mod_perl -- but that's about it.
In other words: HTTP itself is the new CGI. And that still gives you plenty of flexibility about what you choose for an implementation language.
Now you already can't choose/change language easily as you could in past. Service libraries and frameworks - as per project requirements - pretty much define what language one would use.
Not many project requirements dictate specific frameworks -- and they shouldn't.
Services, maybe, but honestly, any service that needs such a huge library that you wouldn't port it to a better platform is too complex a service, and also too rigid a library.
Second, are you sure it will return "hello1.0" and not "hello1.00" or "hello1"?
Actually, I was wrong -- looks like Javascript doesn't have integers, only floats. Which makes it even simpler. In Ruby, it would have done pretty much exactly what I described.
It adds ambeguity to the language and makes me think about something I really should be thinking about.
No one speaks Lojban. Not many people program in Lisp.
I don't think ambiguity is necessarily bad. It is a source of potential errors, but it's not difficult to avoid them -- and it's an easy thing to internalize about a language.
My example isn't as contrived as yours.
It's actually exactly as contrived as mine. Find me a real use case where you need to concatenate a string, an argument, an integer, and then a string.
It turns out, this almost never happens in the real world. There simply aren't that many times you need to put a number into a string -- or at least, that has been my recent experience with Javascript.
With Ruby and Perl, even moreso, since I almost never concatenate strings. In Ruby, the example you wrote would probably be written like this:
"10#{arg1+5}hi"
That's a pretty clear hint -- I'm using '+', and I'm using a numeric, so I probably want arithmetic, not concatenation.
BTW, I'm not too familiar with Ruby. Does it pull the same trick Perl does and use a different operator for string comparison?
No. Ruby generally doesn't coerce types when doing a comparison. That is:
I guess the biggest difference to understand here is that Perl is, at least semantically, a dynamically typed language -- no matter which operator you choose, 5 is '5', and vice versa. Similarly, in Perl, the empty string and the number zero are both treated as false -- Perl doesn't even bother to have an explicit boolean type.
Ruby is actually a statically typed language. It just also happens to be implicitly typed. If I say
a = 5
in Ruby, that value of 5 is an Integer (specifically a Fixnum) -- moreover, since Ruby numeric types are immutable, that 5 will never change. When I do this:
a += 1
I'm actually not changing the value of that 5. I'm just changing which object the variable 'a' happens to point to.
In other words, it's those references -- those actual names (like 'a') -- which are typeless. Actual Ruby objects are, in fact, statically typed. Of course, Ruby is flexible enough to let you do crazy shit like:
class Foo
def class
Bar
end
def is_a? obj
obj.is_a?(Bar) ? true : super
end
def kind_of? obj
obj.kind_of?(Bar) ? true : super
end ... end
and thus frustrate anyone's attempt to force you to rely on static typing -- any object can pretend to be anything it wants, and there is no absolutely reliable way of telling what it is, or what methods it has.
But ultimately, that's all a big lie. You can fool just about every part of the language, but really, it's a Foo, not a Bar.
I am not encouraging crazy shit like that, although it's occasionally useful (ActiveRecord AssociationProxies pretending to be arrays, for example) -- but it is fun to see just how much rope Ruby will give you:
I don't see light DRM as being acceptable if it is just going to be continuously broken days after it comes out. I'd be fine with DRM IF it remains uncrackable...
Is that really relevant, though?
I have a limit to what I will tolerate, as a customer. Whether or not it's effective is between the developer and the pirates.
But so far, I've had to enter a CD key exactly once -- I think it was even copied and pasted. I'm sorry, but the moral outrage simply isn't worth it when that's all that's at stake.
All other things being equal, C or hand-optimized assembly will still be faster than Ruby or Python.
True, and for some things, it will matter.
But take right now -- how many apps are Ruby or Python "too slow" for, on modern processors?
Of course that's ignoring the possibility of a big break through in interpreter and code generation technology before these chips come out.
It seems to be pretty steadily moving along. Just look at the recent JavaScript improvements.
Granted, none of these will be able to match hand-optimized assembly, by definition, because we can always output exactly the same program the compiler would (VM, runtime optimizations, and all), and additionally handle corner cases that the VM might be slower with.
But that distinction is already widely considered irrelevant for C. Games are arguably the place where you'd expect vertical scalability to matter the most, yet most are going to be written in C or C++, with performance-critical bits in hand-optimized assembly. Similarly, almost all dynamic languages provide reasonable ways to write small, performance-intensive parts of your application in C, and leave the rest in your language of choice -- you could even optimize down to assembly there, if it mattered.
Because when you get right down to it, the amount of time you're going to lose simply developing in assembly, let alone debugging, is something you can't afford for the benefit you get.
It's doubtful Crysis would sell a single copy more if it managed to squeeze another 5-10 fps out of equivalent hardware -- everyone would still have to upgrade anyway.
Absolutely not, especially in web development. Do you think Google would still be in business if they stopped developing after Version 1.0? Have you noticed that YouTube is able to react to something as small as an XKCD comic, in order to deliver new features?
No, programming is an ongoing expense. So you want to develop in something maintainable, and in something that can scale, even if you can't scale yet.
Oh, and horizontal scaling is more important than vertical scaling, for pretty much all web apps. Vertical scalability is what you're assuming is important -- squeezing more out of every cycle of a single machine. Horizontal scaling is about making sure that you can simply throw more servers at the problem, and your app will actually be able to run concurrently on multiple cores, and on multiple machines, without falling over.
Also: Programmer time is never going to get cheaper. Hardware does all the time, thanks to Moore's law. Unless that trend stops, my position in this argument will only get stronger every year.
I would imagine it would follow the last release, but I'm not sure anyone really knows.
The last release was available in two forms, that I know of:
- Xbox Live Arcade. The strictest DRM possible (they lock down your entire system and pretend it's an appliance (console) rather than a computer), but it generally works. It's not like you'll be running into "You're not allowed to have this program installed" bullshit with this.
- Greenhouse, their own digital distribution system. Light DRM, somewhat less than Windows XP -- when first installed, or when there's a significant hardware change, it phones home. Unlike XP, this "phoning home" doesn't force you to call someone in India and insist that it's the same computer -- you can install it as many times as you like. But they do reserve the right to notice if you're installing it on a few thousand of your best friends' systems, and disable your key in that event.
So no, not DRM-free, but what I would call an acceptable level of DRM. For example, it's not exactly going to refuse to run because Daemontools is installed.
It actually says nothing about whether or not these microprocessors would be able to operate faster.
But assuming this is real, it one of two things:
Maybe we'll have 200 cores which are about as fast as single cores we have now, in which case, nothing will be slower, and people who planned ahead (like Erlang developers) will find themselves running much faster. On top of that, embarrassingly parallel applications like raytracing will be that much more viable -- consider that it only took 16 cores to make a good Quake 4 raytraced, and this scales linearly.
That, or we have 200 cores, each of which is tens or hundreds of times faster than what we've got now. In which case, WTF do I care that 198 of my cores are doing nothing, when the other two are running my Ruby and Python apps as though they were hand-optimized assembly?
I am making one assumption, though: That RAM keeps up. It would really suck to have 198 cores sitting idle, and the other two mostly just waiting for your RAM.
Show me how that's done in C, so that I can laugh in your face.
If you're talking about performance, you have a point. Unfortunately, it's not a very good one. Programmers are expensive. CPU isn't. And the Web is one place where, if needed, you can simply throw more CPU at the problem.
"Smaller" and "more compact" are properties which are much more useful when applied to the source code, not the result.
Scripting languages are for convenience, nothing more nothing less.
Yes. High-level languages are for convenience.
C is a high-level language.
I'm not kidding. C was a tough sell over assembly at the time. It was actually sold on a lie -- that function calls were cheap. The original Unix spent over half its time in function calls -- but by then, it was too late. People had realized the benefit of high-level languages, and no one wanted to go back to assembly for a whole OS.
Now it's happening again, and you are the crusty old get-off-my-lawn programmer who would still be writing in assembly, if you'd been around when C was the hot new thing.
Native binary languages for *nix system have all the same goodies in them just written at lower levels
Which, by definition, means they don't have the same goodies.
Come back when C can do closures. Or reflection. Or lazy evaluation. Or transparent, opportunistic threading.
These things are useful because they're high-level. If C natively supported them, C would become quite a lot higher-level. As it turns out, you'd have to do quite a lot of low-level work to get these in C, which would defeat the purpose -- or you'd have to build a layer on top of C to handle it for you.
I work with such a layer. It's called Ruby.
and you have to do a little work, or god forbid, some memory management
I have no problem doing memory management, if there's a point. If it has, y'know, any relevance to the problem at hand.
But malloc and free have absolutely nothing to do with rendering HTML, parsing RSS, talking SQL to the database, or any of the other things I'm actually doing.
Sure, they're called behind the scenes, but that's not the point -- so is MOV, CALL, JMP, and so on. Just why is it that you like C, and not assembly?
Scripting languages are for those of a weak mind and poor technical skills and the singular lack of the ability to plan a system out before you write one line of code.
When was the last time you were employed? Scripting languages are for those on a budget and a deadline.
For that matter, what have you done in LISP? If it's the higher-level people who have the "weak mind", it should be easy for you to grok macros, reflection, lambda closures, and iterators, right?
And if you can plan the entire system out before you write one line of code, great, congrats to you.
Except I'll be halfway through implementing it while you're planning it out ahead of time, and I'll be able to actually react when the requirements change. I doubt your superior mind can actually see into the future and predict new things you might have to add.
One more cheap shot before I go -- When you have to port your 32-bit C app to 64-bit, how much did you have to change? It's possible it just recompiled, but for most real-world C apps, it takes at least some effort. And that assumes you've stuck to the subset of POSIX which is reliably implemented everywhere, so you don't have to port between OSes.
Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
That's flamebait.
Perl, I can tolerate. PHP, I can't. But Python has a lot of things to like.
I think it's got more to do with using whatever language you're comfortable with for whatever application you have to write. Sometimes, you run into a wall of sheer unsuitability -- you don't want to write an OS kernel in Perl. But server-side Web development is actually quite forgiving about choice of language -- about the only technical requirement is standard input and output.
Slashdot Mirror
Turns out that when you get it to a usable state, and stop screwing with it, Gentoo works a lot like Ubuntu.
I think Ubuntu provides more, but even assuming that's the case, I'll take Ubuntu any day for the simple reason that precompiled binaries install faster than source code.
Sure, you can use binary tarballs on Gentoo, and you can speed things up with a shared binary cache, and with distcc and ccache (or whatever you kids are using nowdays), but that falls under "screwing with it" -- and if it brings me to something which works as well as Ubuntu, what was the point?
I'm glad I used Gentoo -- it gave me a much deeper understanding of how the OS is put together. But I'm equally glad I no longer use Gentoo.
Note the "even pushing open a door" bit.
And, in this case, when the door was wide open?
For that matter, he did have authorization. If someone gave me the key to their apartment, I could reasonably assume I have authorization.
If I open you unlocked door, and say "Hi" to you on the couch, I'm trespassing. If I open your door, walk in and steal your remote, I'm breaking & entering.
Which is it, then, if you see someone naked through her open window from the street? Or if you take pictures?
I think that's a better analogy -- it's some private information, but ultimately, nothing was taken, and nothing was even broken into. All that happened is some publicly available information was accessed, and possibly copied -- but it shouldn't have been public in the first place.
Sure, you shouldn't have taken pictures, and you should have turned away. But she could've just closed her blinds.
Unfortunately, there's no good way to tell her about it...
Let's play...
Flash: alternatives require hiring an engineer.
My own counterpoint: Flash itself requires hiring an engineer, you just don't know it yet.
The standards are open. The problem is not the proprietary nature of protocols or applications, but that the standards are not obeyed.
There is additionally the problem that proprietary standards (and implementations) tend to evolve faster than open standards, at least on the Internet.
It should travel with all the things that it needs, and you donâ(TM)t need anything more complex than something like X Windows.
This quote is ridiculously out of touch -- X Windows is itself a horribly bloated standard. The difference is, HTML is still mostly useful for its original purpose -- you can still build semantic HTML, style it with pure CSS, and use it to deliver hypertext.
You can't really use X for its original purpose -- I can't reliably access another machine, run an X app there, and have it display on my local X server reliably. Even if it's running the same version of xlib -- if they're different versions, it's going to be even buggier.
You neednâ(TM)t do more than attempt to watch a streaming video on a busy office LAN or oversubscribed DSL circuit to understand that even the best-served markets for Internet connectivity are struggling to keep up with demand for networked content.
If it's the same video, you can stick a caching proxy in front of that LAN...
But really, the death of the Internet has been predicted for ages. Look up Metcalfe's prediction of the "gigaflood" being the end of the Internet...
Eventually, we can just throw bandwidth at the problem. In fact, we can right now -- the amount of bandwidth to send a book, in text format (or even a PDF), is completely irrelevant. It's only when you want to do what isn't feasible yet (stream an HD movie) that you need hacks like CDNs -- eventually, the sheer amount of bandwidth will solve the problem.
We know too that near-universal deployment of technologies with inadequate security and trust models, like SMTP, can mean millions if not billions lost to electronic crime, defensive measures, and reduced productivity.
"Defensive measures" -- Bayesian filters are trivially easy. Captchas are only a problem if you're giving away free accounts, which is completely unrelated to SMTP.
But more importantly, no one has come up with a solution to Spam, SMTP or not, which also provides all the functionality of SMTP.
I don't believe Rails is more crash-prone or scaling-challenged than other platforms. Twitter is certainly not the only site to fall over frequently (look at Myspace). And Rails has been used for much more reliable apps than Twitter.
Anyone can build a shitty app on a good architecture.
All they're doing is making an example out of him.
Wrong example. Unless the email was actually directly threatening something -- and without further details, we just don't know -- the example they're setting is, "Look what happens when you do the right thing! Don't ever tell us when our security is fucked up -- just quietly exploit it, and make sure we don't notice."
Opening a closed but not locked door and entering a building without permission is still against the law. It is called breaking and entering.
IANAL, and I'm just guessing, but wouldn't that be tresspassing? I mean, if you're breaking and entering, I would assume that requires the breaking of something, right?
He has been charged with a crime for something he did, namely "computer trespass" for accessing a system without permission.
There you go.
I would also like to know more about the circumstances. I don't think curiosity should be a crime, and I do think there should be a much more rigid definition of what constitutes "unauthorized access" -- in particular, I think the burden should be to show that the access was, in fact, unauthorized, rather than requiring everyone to keep a clear record of authorization from every site we've ever accessed.
Having read TFA, it looks very much like, by any technological definition, he was authorized. There would have to be pretty clear indications that he wasn't supposed to be there.
And even if he was entirely at fault, this is also entirely the wrong way to go about it. The lesson to be learned here, from any other student who's paying attention, is simply to not tell anyone what you know.
I'm told by /.'s resident graphics devs that, essentially, Dx9 is to them what MacOS X is to power users, and that opengl was clunky, and falling behind.
Some of that is true, and most of it is FUD. Ultimately, it boils down to DirectX giving you more out of the box (in other words, from people who don't know about SDL), and being a more convenient API. Which isn't bad, but if you're developing at the graphics layer, I really hope you're building a better API on top of it -- neither DirectX or GL are a very good game API, and that's what we need.
In terms of raw performance and functionality, neither holds an edge over the other for very long. Having read Carmack's rant, I suspect GL is still faster, but not by enough for anyone to care.
For what it's worth: OS X is one option. I still use Linux, and much prefer it to OS X.
It's just the thin-client model being sold under yet another name.
That or timesharing. Or clustering. Or all of the above.
I'm getting a bit tired of people just throwing a buzzword of last week to try to explain the buzzword of this week...
It's a bit like claiming texting is just email being sold under yet another name. I've been known to do this, to make a point about the price -- but even when the analogy fits, the circumstances are different, and that does matter.
In this case, the thin-client model is often bandwidth-heavy and requires special client software. These "cloud" services (yuck) are actually pretty bandwidth-efficient, and require nothing more than a decent web browser.
If you think about it for a second, they are bandwidth-efficient because they are NOT a thin-client model. The browser is a limited client, but you can still run Javascript, which is now fast enough to rival most other scripting languages.
Combine it with the timesharing/cluster model, and it's going to be more reliable, too.
There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.
That was actually my first thought. What does this do that STOMP doesn't?
Leave it to Microsoft to pick the one I've never heard of...
It would be cool to be able to do a "Speed up my computer" boot where it loads the modules, and then compiles a kernel with the modules for the hardware it finds compiled into it.
This would be both dishonest (it's not just "speeding it up", it's also binding that install to that particular hardware configuration) and pointless (loading modules is simply not a performance bottleneck).
OR, how about loading modules when you actually need them..?
Tricky to get right, and also not necessarily what you want. When your computer goes to suspend or hibernate, you pretty much want every driver loaded, so you can tell it to suspend itself.
There's also the problem where not everything can be triggered that way. Even if the software allowed it (which it doesn't, always), there's the stuff you want to be triggered from outside that computer. Trivial example: Bluetooth. I use a Bluetooth mouse, and I want it to just work when I tell it to connect. I shouldn't have to go type, or worse, click something, to get the bluetooth stuff loaded.
And this goes for daemons, too. When you go to listen to something, and it returns that there's no module loaded for sound, how about loading the module then, and then starting the alsa daemon.
Same applies -- with Bluetooth, you need that daemon running.
Some of this is done -- on KDE3, the arts daemon is only started when something needs it, and is stopped when it's idle for 30 seconds. But some of it is equally pointless.
Now, sure, for lower end machines, I wouldn't use a full Ubuntu. I'd use something stripped down -- either xubuntu, or ubuntu-minimal/server plus fluxbox. But I think the focus has rightly been how Ubuntu works on newer hardware -- that is, after all, the future.
I was pretty much exactly the same.
Turning point for me was realizing that I was compiling more and more in, just in case I needed it, because rebuilding world just to enable that new USE flag was getting kind of old.
In other words, I was using it like Ubuntu. The only advantage I had was I would compile for -march=i686, and other optimizations which produce binaries which only work on recent CPUs (the '686' class) -- whereas Ubuntu was -mtune=i686, if I remember, so it was possible to run on a 486, but would run best on a 686.
And, hey, there were other things I would turn on that were Athlon XP specific, and so on... then I realized that, on amd64, the optimizations were basically exactly the same -- merely compiling for x86_64 gave me all the benefits anyway. At which point, what the hell -- Ubuntu would necessarily be at least as optimized as my Gentoo.
And, more recently, I've realized that since switching to Ubuntu, I spend much more time actually using the OS, rather than tweaking it. Despite having it already much more customized than any version of Windows ever was, I still don't spend as much time tweaking it as it takes to maintain Windows, let alone Gentoo.
If your boss asks you to do something morally questionable, tell him you can't and take the consequences.
Depends how morally questionable. What's the impact?
Your example is borderline Godwin:
So wait, when someone asks you to invade Iraq and kill anywhere between 500.000 and 1.000.000 natives your answer would be "I'll e-mail you that this is a rather bad idea, but if you clarify the request, I'll do it"?
We're not talking about killing hundreds of thousands of people. We're talking about scraping a fucking website. At the end of the day, worst case, this starts costing said website some money, and they either sue your company (and your CYA will protect you), or they'll start blocking you, or they'll feed you bad data.
In either of the above cases, you've cost someone some money -- not hundreds of thousands of lives, but some increased bandwidth bills and some time -- and you've also taught your boss a lesson he'll never forget.
Of course, if you're going to be idealistic about it, why would anyone be working for this tool in the first place? If you can answer that question, you might also be able to answer why someone might want to continue working with this tool.
I vaguely remembered Steam, and I Googled for it, but all I found were references to the Penny Arcade strips themselves being available on Steam, which seems like a retarded idea. (Why would you want them via Steam, rather than via Firefox?)
I'll take your word for it. Irrelevant to me, as I bought it for Linux.
CGI days (only technical requirement is standard input and output) are long gone.
Well, not really. It still works. Your biggest complaint:
You gonna end up with huge performance problems unless you would use something more modern and advanced than trivial piping.
That is a vertical scaling concern. If vertical scaling is that important to you, consider using C, instead.
Not that it's unimportant. I'm just saying -- if all we had was CGI, there's no reason we couldn't still throw hardware at the problem.
No, I was talking about things like FastCGI, or even more relevantly, in-application webservers. It turns out, talking HTTP really isn't that hard. Ruby has, by my count, six separate in-application webservers supporting the common Rack API.
Throw a load balancer like nginx in front of them, and what do you need Apache for? Other than old apps which were tied too closely to it -- some mod_php (though those mostly tend to work with php as fcgi), and especially some mod_perl -- but that's about it.
In other words: HTTP itself is the new CGI. And that still gives you plenty of flexibility about what you choose for an implementation language.
Now you already can't choose/change language easily as you could in past. Service libraries and frameworks - as per project requirements - pretty much define what language one would use.
Not many project requirements dictate specific frameworks -- and they shouldn't.
Services, maybe, but honestly, any service that needs such a huge library that you wouldn't port it to a better platform is too complex a service, and also too rigid a library.
Second, are you sure it will return "hello1.0" and not "hello1.00" or "hello1"?
Actually, I was wrong -- looks like Javascript doesn't have integers, only floats. Which makes it even simpler. In Ruby, it would have done pretty much exactly what I described.
It adds ambeguity to the language and makes me think about something I really should be thinking about.
No one speaks Lojban. Not many people program in Lisp.
I don't think ambiguity is necessarily bad. It is a source of potential errors, but it's not difficult to avoid them -- and it's an easy thing to internalize about a language.
My example isn't as contrived as yours.
It's actually exactly as contrived as mine. Find me a real use case where you need to concatenate a string, an argument, an integer, and then a string.
It turns out, this almost never happens in the real world. There simply aren't that many times you need to put a number into a string -- or at least, that has been my recent experience with Javascript.
With Ruby and Perl, even moreso, since I almost never concatenate strings. In Ruby, the example you wrote would probably be written like this:
That's a pretty clear hint -- I'm using '+', and I'm using a numeric, so I probably want arithmetic, not concatenation.
BTW, I'm not too familiar with Ruby. Does it pull the same trick Perl does and use a different operator for string comparison?
No. Ruby generally doesn't coerce types when doing a comparison. That is:
You can, of course, force the issue:
I guess the biggest difference to understand here is that Perl is, at least semantically, a dynamically typed language -- no matter which operator you choose, 5 is '5', and vice versa. Similarly, in Perl, the empty string and the number zero are both treated as false -- Perl doesn't even bother to have an explicit boolean type.
Ruby is actually a statically typed language. It just also happens to be implicitly typed. If I say
in Ruby, that value of 5 is an Integer (specifically a Fixnum) -- moreover, since Ruby numeric types are immutable, that 5 will never change. When I do this:
I'm actually not changing the value of that 5. I'm just changing which object the variable 'a' happens to point to.
In other words, it's those references -- those actual names (like 'a') -- which are typeless. Actual Ruby objects are, in fact, statically typed. Of course, Ruby is flexible enough to let you do crazy shit like:
and thus frustrate anyone's attempt to force you to rely on static typing -- any object can pretend to be anything it wants, and there is no absolutely reliable way of telling what it is, or what methods it has.
But ultimately, that's all a big lie. You can fool just about every part of the language, but really, it's a Foo, not a Bar.
I am not encouraging crazy shit like that, although it's occasionally useful (ActiveRecord AssociationProxies pretending to be arrays, for example) -- but it is fun to see just how much rope Ruby will give you:
I don't see light DRM as being acceptable if it is just going to be continuously broken days after it comes out. I'd be fine with DRM IF it remains uncrackable...
Is that really relevant, though?
I have a limit to what I will tolerate, as a customer. Whether or not it's effective is between the developer and the pirates.
But so far, I've had to enter a CD key exactly once -- I think it was even copied and pasted. I'm sorry, but the moral outrage simply isn't worth it when that's all that's at stake.
All other things being equal, C or hand-optimized assembly will still be faster than Ruby or Python.
True, and for some things, it will matter.
But take right now -- how many apps are Ruby or Python "too slow" for, on modern processors?
Of course that's ignoring the possibility of a big break through in interpreter and code generation technology before these chips come out.
It seems to be pretty steadily moving along. Just look at the recent JavaScript improvements.
Granted, none of these will be able to match hand-optimized assembly, by definition, because we can always output exactly the same program the compiler would (VM, runtime optimizations, and all), and additionally handle corner cases that the VM might be slower with.
But that distinction is already widely considered irrelevant for C. Games are arguably the place where you'd expect vertical scalability to matter the most, yet most are going to be written in C or C++, with performance-critical bits in hand-optimized assembly. Similarly, almost all dynamic languages provide reasonable ways to write small, performance-intensive parts of your application in C, and leave the rest in your language of choice -- you could even optimize down to assembly there, if it mattered.
Because when you get right down to it, the amount of time you're going to lose simply developing in assembly, let alone debugging, is something you can't afford for the benefit you get.
It's doubtful Crysis would sell a single copy more if it managed to squeeze another 5-10 fps out of equivalent hardware -- everyone would still have to upgrade anyway.
Could have pointed to a timecode. Seems to be about 19 and a half minutes in.
I wasn't wanting to start a flamewar of language vs language. I'll defend a lot of features of Ruby, and I'll point out fundamental flaws in it...
But I think we can agree that web services should almost never be written in C, when there's any higher-level option.
Snicker. You've just offloaded your incompetence to a small army of IT personnel that now needs to keep a farm of servers running 24x7.
s/incompetence/work. After that... so what?
That army is expensive, the datacenter that needs to be used is expensive.
It's really not.
The programmer is just a one time expense.
Absolutely not, especially in web development. Do you think Google would still be in business if they stopped developing after Version 1.0? Have you noticed that YouTube is able to react to something as small as an XKCD comic, in order to deliver new features?
No, programming is an ongoing expense. So you want to develop in something maintainable, and in something that can scale, even if you can't scale yet.
Oh, and horizontal scaling is more important than vertical scaling, for pretty much all web apps. Vertical scalability is what you're assuming is important -- squeezing more out of every cycle of a single machine. Horizontal scaling is about making sure that you can simply throw more servers at the problem, and your app will actually be able to run concurrently on multiple cores, and on multiple machines, without falling over.
Also: Programmer time is never going to get cheaper. Hardware does all the time, thanks to Moore's law. Unless that trend stops, my position in this argument will only get stronger every year.
I would imagine it would follow the last release, but I'm not sure anyone really knows.
The last release was available in two forms, that I know of:
- Xbox Live Arcade. The strictest DRM possible (they lock down your entire system and pretend it's an appliance (console) rather than a computer), but it generally works. It's not like you'll be running into "You're not allowed to have this program installed" bullshit with this.
- Greenhouse, their own digital distribution system. Light DRM, somewhat less than Windows XP -- when first installed, or when there's a significant hardware change, it phones home. Unlike XP, this "phoning home" doesn't force you to call someone in India and insist that it's the same computer -- you can install it as many times as you like. But they do reserve the right to notice if you're installing it on a few thousand of your best friends' systems, and disable your key in that event.
So no, not DRM-free, but what I would call an acceptable level of DRM. For example, it's not exactly going to refuse to run because Daemontools is installed.
It actually says nothing about whether or not these microprocessors would be able to operate faster.
But assuming this is real, it one of two things:
Maybe we'll have 200 cores which are about as fast as single cores we have now, in which case, nothing will be slower, and people who planned ahead (like Erlang developers) will find themselves running much faster. On top of that, embarrassingly parallel applications like raytracing will be that much more viable -- consider that it only took 16 cores to make a good Quake 4 raytraced, and this scales linearly.
That, or we have 200 cores, each of which is tens or hundreds of times faster than what we've got now. In which case, WTF do I care that 198 of my cores are doing nothing, when the other two are running my Ruby and Python apps as though they were hand-optimized assembly?
I am making one assumption, though: That RAM keeps up. It would really suck to have 198 cores sitting idle, and the other two mostly just waiting for your RAM.
You can write smaller, more compact & light weight server side programs in C then you can for just about anything else.
You obviously haven't seen just about anything else. I present Sinatra as Exhibit A:
Show me how that's done in C, so that I can laugh in your face.
If you're talking about performance, you have a point. Unfortunately, it's not a very good one. Programmers are expensive. CPU isn't. And the Web is one place where, if needed, you can simply throw more CPU at the problem.
"Smaller" and "more compact" are properties which are much more useful when applied to the source code, not the result.
Scripting languages are for convenience, nothing more nothing less.
Yes. High-level languages are for convenience.
C is a high-level language.
I'm not kidding. C was a tough sell over assembly at the time. It was actually sold on a lie -- that function calls were cheap. The original Unix spent over half its time in function calls -- but by then, it was too late. People had realized the benefit of high-level languages, and no one wanted to go back to assembly for a whole OS.
Now it's happening again, and you are the crusty old get-off-my-lawn programmer who would still be writing in assembly, if you'd been around when C was the hot new thing.
Native binary languages for *nix system have all the same goodies in them just written at lower levels
Which, by definition, means they don't have the same goodies.
Come back when C can do closures. Or reflection. Or lazy evaluation. Or transparent, opportunistic threading.
These things are useful because they're high-level. If C natively supported them, C would become quite a lot higher-level. As it turns out, you'd have to do quite a lot of low-level work to get these in C, which would defeat the purpose -- or you'd have to build a layer on top of C to handle it for you.
I work with such a layer. It's called Ruby.
and you have to do a little work, or god forbid, some memory management
I have no problem doing memory management, if there's a point. If it has, y'know, any relevance to the problem at hand.
But malloc and free have absolutely nothing to do with rendering HTML, parsing RSS, talking SQL to the database, or any of the other things I'm actually doing.
Sure, they're called behind the scenes, but that's not the point -- so is MOV, CALL, JMP, and so on. Just why is it that you like C, and not assembly?
Scripting languages are for those of a weak mind and poor technical skills and the singular lack of the ability to plan a system out before you write one line of code.
When was the last time you were employed? Scripting languages are for those on a budget and a deadline.
For that matter, what have you done in LISP? If it's the higher-level people who have the "weak mind", it should be easy for you to grok macros, reflection, lambda closures, and iterators, right?
And if you can plan the entire system out before you write one line of code, great, congrats to you.
Except I'll be halfway through implementing it while you're planning it out ahead of time, and I'll be able to actually react when the requirements change. I doubt your superior mind can actually see into the future and predict new things you might have to add.
One more cheap shot before I go -- When you have to port your 32-bit C app to 64-bit, how much did you have to change? It's possible it just recompiled, but for most real-world C apps, it takes at least some effort. And that assumes you've stuck to the subset of POSIX which is reliably implemented everywhere, so you don't have to port between OSes.
I
That link compares PHP to Perl.
And pretty soundly shows Perl to be as good as or better than PHP, in some fundamental ways.
I spit on Perl and so does everybody else I know.
You apparently don't know a lot of people who actually understand Perl.
Pretty much natural choice for all who can't (or refuses) to grok Perl, yet want to have a real language at their disposal.
That's flamebait.
Perl, I can tolerate. PHP, I can't. But Python has a lot of things to like.
I think it's got more to do with using whatever language you're comfortable with for whatever application you have to write. Sometimes, you run into a wall of sheer unsuitability -- you don't want to write an OS kernel in Perl. But server-side Web development is actually quite forgiving about choice of language -- about the only technical requirement is standard input and output.