Better to be a bit of an unfair bully than to do sit around while parasites send the industry down the toilet. It's like chemotherapy: sometimes you have to hurt the body to kill off the cancerous cells.
What a narrow-minded position. RMS is mostly harmless, has brought some good things into this world, and provides a reliable reservoir for a particular set of ideals. Nobody has to agree with him for him to be useful. He's operating within the confines of the law. He is not trampling on anyone's rights. He is worth 100 people who just compromise everything away for short term gain. He's like Ron Paul; kind of a nutter, but a necessary antidote for these times.
How are you going to ensure that "lab-grown meat" is not going to lack something important contained within farm grown meat? We already know that the composition of the meat changes depending on what you feed the animals. What about micronutrients we don't know about? Man has not supplanted nature in cleverness.
I don't know why I'm being downvoted for a simple question, but my point was that I don't see how this it's ever going to be possible to demonstrate that these things are safe. Our ancestors ate game meat, not farm meat. And now people want to grow it in a lab? I'm not saying we can't make a trade-off here, but people focus on the things they can see and ignore the unknown (in this case, the health effects of eating a new kind of processed food).
HTML5 is critically dependent upon hardware acceleration. So anything that can't be hardware accelerated wherever the games are running will be slow. If your drivers are bad it will be slow. The next step will be people creating ridiculously complex JIT setups just to get back somewhere near native throughput. Note that is _throughput_, not latency. Every layer of abstraction adds more unpredictable pauses and non-reproducible glitches. All so people can slap together the next Angry Birds clone with zero technical artistry.
>It was hard for me to write them off as people who just didn't understand how modern computers work.
I'm glad you didn't fall for that trap. Software engineers constantly make excuses for doing things in idiotic ways. Almost nothing I use really works anymore. It just "kind of" works most of the time. Look at your average web applicaton and the ridiculous resources it takes to get the thing up on the screen and interacting with the user. We've become addicted to high powered machines and finding more complex and inefficient ways of doing the same things.
Absolutely agree. I was playing with a BBC Micro last night, 2Mhz processor and 52k RAM (shadow RAM card fitted, and 16k sideways RAM - this is a beast of a machine!). Then I did some stuff on my 2x2.4Ghz, 4G RAM Mac, and I almost punched the damn thing in frustration, 2000x "faster" and it can't even keep up with my typing!
Well, maybe I'm not in that trap now, but I was for a long time.
> Almost nothing I use really works anymore.
I'm hoping that I can hide from that inside the Emacs monastery. That didn't seem to work for jwz though, so I'm not sure if there's a way to avoid having to update my silly software several times a decade.
JFC! I've been going through this at work today - the developers of a third-paty app designed the app for low utilization companies - our company is a bad fit for this software. We're in the top 500, and our usage patterns expose every scalability flaw in this software...
And then we'd have had people writing applications that Lisp isn't suited for complaining at what could have been if only we'd gone with a simple register architecture. Don't get me wrong - I believe in owning the whole stack, and I'd love to see some Lisp machines. I fully believe that something like this may reappear in the future. But let's not kid ourselves: none of these singular visions of simplicity is going to be good enough for everything.
It's not necessarily the case that Lisp machines would be the only way. I'd think more like what Intel is doing these days, adding instructions to SSE to speed up things like string processing.
I don't see the connection between Lisp machines and JavaScript. JavaScript (in the browser at least) is a heavy-weight C++ system utilising huge amounts of library and operating system code with some weak scripting capabilities a the bottom. What relation does that have to Lisp machines or Smalltalk type environments where everything is built in a simple an transparent manner?
You're right, it's a weak connection right now. I could be wrong, but I'm seeing JavaScript getting pushed "down" the stack. People are doing things like implementing the DOM in pure JavaScript. I'm also very interested in seeing what people are doing with Emscripten, ClojureScript, swank-js, and the like.
Yes, we don't have a Lisp or Smalltalk like environment for JavaScript. Not yet. Given how widely supported JavaScript is though, I could see us getting there organically? Not sure.
lispm, I've tried looking up the link you posted a year or so ago to a gallery of Genera software screenshots, but it doesn't seem to be working (lispm.dyndns.org). Have you moved the gallery somewhere else? Please let me know, I'm very interested in seeing how they look!
Given that Mozilla aren't willing to redesign their browser to eliminate the recurring flaws, I find it implausible that they're going to go for a balls-out JavaScript-all-the-way-down approach. The way it's going now is more C++ code to do specialised tasks with a bit of scripting on the front. Is stuff like Emscripten getting us closer to a half-way decent design? It seems like this is all just enabling more complexity. Now we'll have C code compiled to JavaScript compiled to machine code.
I like Embscripten and so forth for hack value, but this is a terrible way to build systems. I mean, people want sandboxed code in the browser, so why not make the whole browser sandboxed? Because nobody cares enough to put the effort in, I guess. Chrome is the only browser going along these lines and Mozilla is doing its best to hose down that effort because it just might allow people to program for a simple portable VM instead of all this application-parading-as-a-platform web standards stuff.
I wasn't clear. I wasn't meaning to suggest that Chrome were going to move away from C++. But they are trying to sandbox using NaCl and other mechanisms. I was aware of the Rust effort, but not that they were going to implement more of the DOM in JavaScript (thanks!). Maybe there will be more security-by-design.
I also think JavaScript is a bad basis for a platform in any case, since it requires loads of complexity to be fast. Why not just a simple typed language or VM? I have read some JS JIT papers and they have found plenty of code generation bugs (more security holes).
I don't think Chrome is trying to sandbox their own code using NaCl, so much; they're just trying to sandbox "arbitrary executable" code.... which is sandboxed automatically if it's JS running inside a JS VM instead of a random binary blob.
For the rest, one of the main points of Rust and servo is to have better security-by-design. Whether the DOM ends up implemented in JS or in Rust is still up in the air at this point, but either one would be much better than C++ from a security perspective.
As for JavaScript, it's what we have due to happenstance, but displacing it involves either a huge amount more complexity in web browsers (to support JavaScript _and_ another language both touching the same objects and whatnot without memory leaks) or just dropping JS entirely and implementing some other language (not exactly likely to succeed). Maybe someone will create a VM that can run both JS and something else well. Maybe. It's not all that simple to do.
You and I are starting from different assumptions. I want to throw out the DOM. It is an application-specific component that should be implemented in "user land". Currently we're heading toward C inside JS inside Rust, with plugins written in C++ running outside any sandboxes. This is never going to be secure. You have to design a VM that everything can sit in. There's no reason why a browser can't sit inside a simple VM except that it builds in huge amounts of complexity regardless of how its used.
We don't need a VM to run JS "well". Nothing going on in the browser is even CPU intensive if not for the huge gobs of complexity going on. People are making simple things harder and harder to do, and complex things easier and easier. If you just write everything for a simple typed VM you don't have to bend over backward to make things run fast. There's nothing going on in the client side of say, GMail, that I couldn't do (faster!) on the computer I was using in 1997.
>That's not quite true. People do in fact do CPU intensive stuff in browsers, if nothing else because they write algorithmically slow code.
It's CPU intensive because of the way it's done, not because it intrinsically requires much CPU. That was my point. And it's not just algorithms; everything goes through a million layers of abstraction.
>Note that GMail is not an example of an application that really does intensive JS. A photo editing app would be a better example.
Again, I was doing photo-editing years ago with no troubles. You wouldn't even be able to start your JS photo editing app on a 1996 computer. And by focusing on "CPU-intensive" tasks you're missing an essential point, which is that stuff that shouldn't require any CPU does. My system shouldn't pause - ever. We have optimised everything for high throughput on powerful machines. The JVM suffers from exactly this problem. Java is plenty "fast" if you ignore latency.
There's just nothing demanding enough to require that going on. And yet the UI locks up for 1-2 seconds pretty frequently on my $1000 desktop machine with loads of RAM and CPU. It's even worse on my $400 laptop. There's nothing intrinsic in the hardware or the tasks that should cause this to happen - it's the design of the software. It's because the system is too complex and preemptable that this happens.
Oops. In the above I said the system shouldn't pause ever. This is silly of course. What I meant to say is that it shouldn't pause except when hit with hard resource limits. Loading from the disk or performing an expensive calculation will take some time of course. But there shouldn't be random pauses when interacting with something that ought to be fit into memory. Modern systems are full of pre-emption, GC pauses and other non-determinisms.
I have a real beef with this "reasoning from axioms" stuff when it gets taken as a dogma. Maybe you don't take it as a dogma. I am also yet to see a working libertarian society, so it's all just academic posturing as far as I'm concerned, much like all this atheist utopianism I keep hearing about. Frankly, I don't see anything intrinsically immoral about forcing other people to do or not do things using force. You can't opt out of society with the numbers we have now.
The problem as I see it is not adhering to some principle or another it's that everything is too big and too centralised. I like a lot of what people like Ron Paul are saying, but if we were to give them a free run for a few decades we'd need a new reactionary movement to undo all the problems resulting from their own excesses. People need to let go of the idea that a person can "crack the code" of society and figure out the right ethics for all time.
What is unethical about that? The video was going to get views anyway, I was just helping it out. It's like the snowball effect that would occur naturally, except they start with a bigger snowball. I don't do this stuff anymore though, that was when I was younger and in college.
I'm not saying you're a bad person. Hell, I've done plenty of unethical stuff in my time. But generating fraudulent views is a clear abuse of the system. You're simply rationalising it away.
Your assumption is that a 'clear abuse of the system' is unethical. Overflowing a char buffer to get control of EIP is also a 'clear abuse of the system', yet I have a hard time qualifying that (by itself) as unethical.
