I think the difference here is that Comcast most likely has something about this in their contract -- so users have already agreed to it.
Also, what networks do you have the right to set up a resolver for? Comcast isn't technically "intercepting" anything -- these are requests going directly to their nameservers, that they then decide what to do with.
Me, I'm using them for the performance boost. I've already got a local cache in the form of dnsmasq, and of course, OSes and browsers probably do some caching of their own. But that initial lookup, I'm getting on the order of 150 ms from my ISP's DNS, and about 30 from Google, for the same query.
Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.
We delete these temporary logs within 24 to 48 hours.
In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena and improve the Google Public DNS prefetching feature. We don't correlate or combine your information from these logs with any other log data that Google might have about your use of other services, such as data from Web Search and data from advertising on the Google content network. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.
So in other words, for less than two days, their DNS log, and nothing else, will know that a particular request was made from a particular IP. Other than that, they'll know that someone from your ISP, or perhaps from your whole fscking city, made that request -- maybe. I'm guessing they'll be looking at overall trends.
Except in this case, they claim your IP will be gone from their logs in 24 hours, and it'll never be associated with anything else you do at Google.
My guess is, they want broad statistics like the most popular domains visited, maybe even traffic patterns of which domains people tend to go to after which other domains.
So you're right, the motives are quite transparent. Except in this case, I have no idea why I wouldn't want to participate. It's likely to be a hell of a lot more responsive than my ISP's DNS.
$ host slashdot.org slashdot.org has address 216.34.181.45 slashdot.org mail is handled by 10 mx.corp.sourceforge.com. $ host slashdot.org 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases:
slashdot.org has address 216.34.181.45 $ host 216.34.181.45 45.181.34.216.in-addr.arpa domain name pointer slashdot.org
You, sir, are a liar.
Cue *whoosh* in 3..2.. actually, I still don't get it. Either you're trolling because you hate Google, or there's some obscure joke that I still don't understand. I really don't get how your list of crap it requires (most of which doesn't exist or doesn't apply to DNS) is funny -- are Google known for requiring random stuff like that?
I mean, they don't even touch NX:
$ host aoeusnth.com Host aoeusnth.com not found: 3(NXDOMAIN) $ host aoeusnth.com 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases:
Host aoeusnth.com not found: 3(NXDOMAIN)
That's more than you can say for most ISP-level resolvers.
That's a bit like saying, if you need to write a program, someone has failed.
Now, if you need to be in the commandline to do something which an ordinary user should be able to do, for which there is a sane GUI equivalent, I agree -- that shouldn't happen.
However, there are and always will be things which are easier to do with a commandline, and things which can't really be expressed elsewhere. The use of pipes alone warrants that.
A fun example would be taking a disk image, checksumming it while compressing it lightly and sending it through an encrypted tunnel to a server, as with light enough encryption, this will actually be faster than sending it unencrypted -- especially if the destination drive is slower/busier than the source drive... then, when it's done, transfer the checksum to the server and have the server decompress the image while verifying the checksum, then immediately re-compressing it with much heavier compression, taking several hours...
You could argue that specific parts of this could be done better -- maybe I should checksum the compressed file so I know sooner. Then again, my way means I'm also checking the compression itself -- it means I absolutely am getting out of the other end the same thing that was on disk. You could also argue that I should bundle all of this into a piece of GUI software designed for taking disk images -- debatable, but I can go with that.
But the fact that I need the commandline to do that now isn't a bug, it's a missing feature. In this case, the commandline is almost acting as a kind of software development -- and it is, after all, Turing-complete.
I'd argue that if you need a GUI for something, that's also a failure. GUIs aren't reliably or easily scriptable, and the concept of pipes doesn't really apply. The above procedure would work, if the GUI had been developed with it in mind -- but it'd have to be a very specific GUI, whereas on the commandline, the compression tools, checksum tools, imaging tools, and encrypted tunnel, are all completely independent and generic -- the same compression tool that I might use to unpack a tarball will also handle a disk image. The same imaging tool which could create a file on an external hard drive can also stream the image over the Internet -- all without knowing anything at all about either of them.
Well, back in the day, it would've been 'man cdrecord', which kind of makes sense. I honestly don't remember how I learned about cdrecord, or how I now know it's been renamed to wodim.
In all honesty, I suspect us Linux users have some sort of telepathic network...
However, trying some of the other questions gives some useful responses:
apropos burn
gives me k3b. Knowing that it's a KDE program, I might then look in the menus to see if it's a GUI program. It is, so I'm done.
houghi points the way to another possible answer. Personally, I'd Google for linux burn cd commandline -- the tutorials returned are out of date, but still work. 'man cdrecord' doesn't give me anything, but 'which cdrecord' tells me it exists, and 'ls -lh `which cdrecord`' tells me it's wodim. So, 'man wodim' gives me the most relevant, though least userfriendly, documentation.
Note, none of this is at the expense of the fact that when I pop in a blank CD, I do get a GUI popup that lets me point-and-click to burn a CD. Since I'm on KDE, this probably leads to k3b, though I haven't used it in awhile.
Well man just confused me more than anything else.... just listing out a whole bunch of switches with some description of what they do that itself doesn't actually mean anything to me, isn't enough.
As a newbie, I remember man actually being useful, sometimes. First, read the name and the description -- these will generally tell you what the command does. In general, if you don't understand at least the name, you don't need to use that program -- for example:
gcc - GNU project C and C++ compiler
If you know what C and C++ are, and what a compiler is, that makes sense. If you don't know what they are, do you need to be using gcc at all?
Once you've got that, usually the synopsis will give you an idea of how it should be used, and what options to look at. If not, look for the examples.
And try info, not just man. It takes just a bit more effort to learn info, and you'd be much better off finding some sort of web-based info browser, but if the program does have an info page, that's likely to be much better organized and easier to understand.
At least, I think that's what worked for me. I actually learned how to use things like gcc and tar from man and info, and I didn't find it particularly difficult.
On the other hand, I was 15, so I'm not really sure how I did it, and it's possible 15-year-olds are just better at learning these things, when motivated.
Google reveals a lot of very helpful and well-written newbie guides though. Perhaps the best of those should be adapted and built-in to the documentation shipping with new distros?
I'd argue they should be mirrored, perhaps absorbed into version control and/or the wiki of the project in question, but I don't see how including them on the CD is that helpful. What would be much more helpful are some meta-tutorials, like how to Google intelligently, how to find the project mailing list -- or failing that, an email address of someone responsible -- and how to ask smart questions -- though it might be easier to start here.
The reason is that no distro could ever include every possible tutorial, or keep them entirely up to date, though it would still be useful to try. It would be much more useful to train users to find the best possible documentation, and when that fails them, ask the best possible questions.
You can also run all of Windows 7 through a disassembler and you can make changes to your own system with a hex editor editing DLL libraries by hand. That's nearly the same kind of "documentation" and "openness" as far as most users are concerned...
Well, most users won't be able to do either, it's true. But if they actually wanted to make an effort, the learning curve for editing source code is far less.
It's also worth mentioning that the open-ness does, in fact, have visible results. One example is an open bug tracker, which you won't often find on a closed source project -- you can actually submit a bug and watch developers handle it (or ignore it). Another example is the ability to fork a project and add features -- the fact that individual users can't do it doesn't mean they can't reap the rewards when other developers do. A good example here might be Iron, a fork of the Google Chrome browser.
Documentation absolutely is important, and there are large gaps. We do have some of the important bits -- man pages, plenty of stuff on Google, and the README and HACKING documents provided with source code, for those who actually want to make changes.
But then, plenty of people do find sufficient documentation to develop an understanding. You say "none of these exist", but the sheer number of contributors to the Linux kernel should be evidence that they do, to some extent.
I can access help files with a mouse click, too, where it makes sense.
For comparison, open up a Terminal in Mac OS X, and tell me what you find for documentation. In fact, I dare you -- try the same with start->run->cmd on Windows.
If you're already in a commandline environment, man makes sense, and Google makes sense as a way to find out about man. I know of no OS which provides point-and-click help for the commandline, nor can I think of a sane way to do it.
SETI@HOME is doing intense math calculations using as much CPU as it can. Starry Screen Server is not.
It sounds as though you're arguing that SETI uses more power. I was replying to a post which claimed that doesn't matter at all. That's what I'm disputing here.
who to allow? Even fortune 500 are getting compromised left and right.
I think you're being a bit overly-dramatic, but to answer your question, allow the ones you want to. You still get the added benefit that not every Slashdotted article or Google search is a potential vulnerability.
My paranoia is justified I think.
I really don't agree. If you run a decent browser, and keep it patched, it just doesn't seem likely to me. Besides, all you're doing is adding another layer -- if you can't keep your browser patched/secured, what makes you think you can do the same to a VM? They're both just sandboxes.
Besides, if you're willing to go to those extremes, might I suggest a sandboxing browser? On Linux, Chrome seems to be chrooting parts of itself, thus a Javascript vulnerability would only affect one or two tabs, and would need to exploit an additional Linux vulnerability to reach outside of that.
I just hate the thought of becoming the cause of another annoyance in a few thousand people's day as they click delete on the spam my machine sent them.
Good for you! That is admirable.
I'm just questioning whether your approach is warranted. As an example, wouldn't it make more sense to install a firewall -- best way would be as a separate machine, maybe configure your router, etc -- to both block outbound SMTP, and notify you if anything tries?
In other words, be scientific about it. Instead of getting paranoid by reading a lot of security research, actually find out whether either your VM or your host has become a "pox riddencompromised bit bucket", or how often that happens.
It isn't that he was using more, or even less, electricity by running SETI@Home.
Really?
The fact that he was using government electricity for non-governmental purposes is the problem. It is no different than hooking up a hose to a county fire hydrant to fill your personal swimming pool. You benefit, they pay.
Suppose someone left that hydrant running?
If he was using more electricity, you have a point. If he was using less, I really don't see the problem -- and I'm including here the question of whether they were on when they shouldn't be.
Most of today apps use JS in browser and something other on server. This is BAD, no matter how cool JS itself is.
Why is this bad?
I mean, I don't entirely disagree, but it seems a minor issue, really. After all, unless you're using CouchDB, your database queries are written in some query language (probably SQL), which is entirely different than the language your server-side app is developed in.
As browser is becoming a full-fledged platform, it is screaming for support of other languages along side with JS.
And some browsers support this. There are also other ways of doing it -- for example, JRuby as an applet, or various Silverlight bastardizations.
When I talk about an object oriented programming language I'm referring to a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way.
Please provide an example of how Javascript doesn't do this.
I'm aware that it isn't completely homogeneous in the same way that, say, Ruby is. I challenge you to show me an example of this that actually matters.
I don't want to write a library and helper methods to write an OO program, I want to use the language.
So when you write C++, do you never use the std namespace? When you write Perl, do you completely ignore the existence of CPAN?
People have already written libraries that implement many of the ideas of "traditional" OOP, though if you talk to the person who actually coined the term, most of those "traditional" ideas really aren't.
I think it speaks to the power of a language when whole paradigms like that can be written as libraries. It means that the language is multiparadigm without even trying. And it's always nice to see something you'd think of as a core language feature, even a keyword, but it's possible to express it naturally as library code.
It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript,
This is a non-sequitur. Javascript is built on prototypical inheritance, which does not rely on classes.
I'm guessing you found that "private" page -- and enforced-private stuff is not a requirement of OOP, by the way -- but you probably found it here, right? Shortly after that link is another -- this explanation of inheritance in Javascript.
just stop trying to force it to be something that it was not meant to be (that is a general purpose language to write medium to large scale applications).
The fact that it wasn't "meant" to be isn't entirely relevant. It does explain some of the problems we see with it -- I certainly won't claim it's perfect -- but can you explain why Javascript isn't suitable for medium to large scale applications?
I don't. Think about it -- every opening tag must have a corresponding closing tag, which is at least as long as the opening tag name. I mean, I could pretty easily rant about stuff like that -- you could pretty easily make a much more readable markup language, and people have.
But really, just look at JSON or YAML sometime -- they are much better at representing structured data -- they're smaller, lighter, and easier for humans to edit and understand. XML is good for markup, but even here, tools like markdown tend to be better, at least at being human-editable.
"checked" could still have been 0/1 even as a string, having a whole word seems longwinded, it isn't like web designers don't know what boolean is.
Actually, yes, it would've been annoying as hell to have to look that up every time. I know I'd be wondering if that is in fact a boolean, or if it's a count of some kind -- what would it mean to set checked=2?
Never mind that not all programming languages use 0 and 1 as boolean values. The better ones have a separate concept of true and false.
Now, maybe checked='checked' is a bad idea, and it should've been checked='true', but wasting an extra few characters in something that's going to be gzipped anyway, where you're already automatically wasting a ton of characters on every document just by using closing tags?
Go try Haml. Actually learn it and use it for a few pages. See if you don't like working with it a lot better than raw HTML -- or XML, even.
ID could have been reused for names automatically with no issues. IDs have no real requirement to be unique, could have had them replace classes as well with no issues.
document.getElementById is a lot nicer when you have a unique ID.
Yes, IDs do have a requirement to be unique. Try running your document without unique IDs through the W3C Validator, see what you get.
And no, you can't re-use IDs as names, as then you can't have multiple forms on the page with duplicate names. That is, right now, I can have two separate forms which submit to the same place, with mostly different options but some overlap -- say, "search" and "advanced search". Or I could have forms that submit to completely different servers, and there happens to be some overlap of field names.
So the only thing you're left with is re-using classes as names. That doesn't work either, because you can have multiple classes per form element (what would that mean?), and it also means that the behavior of the form is now tightly coupled to its visual representation.
That is, say you had a bright read style called "urgent". And say you had a form with a checkbox called "urgent". Can you see why it might be confusing if you had some other form element you wanted to style as urgent?
Now, you could make a valid case that if you're using a nice library like jQuery, there isn't really an advantage to IDs -- you could just use classes for everything, with a convention that certain classes be unique. I'd disagree -- the fact that IDs are unique, and that you're applying them to things which actually are guaranteed to be unique on a page, gives you a very simple tool (any HTML validator will do) to ensure that you don't have any duplicate IDs.
the way css styles are applied is strange though that may be css' fault.
Citation needed.
It seems to me that the biggest issue with CSS is browser implementation. Easily 90% of that goes away if you stop supporting IE. The rest of it is useful if you
And people use it. Unless webpages are all div/span tags with a link to the css then people are using html for formatting. (yes, even header tags count since they change font sizes)
*facepalm*
If you use header tags just to change the font size, then sure. Maybe.
But that's not the point, and it's also not necessarily what happens. Just
Do away with client side browser scripting entirely and replace it with applications written in Javascript.
Why?
I mean, the main reason people write client side browser applications isn't JavaScript, it's that they're browser applications.
I don't like the requirement that I have to allow most websites to run essentially arbitrary code on my machine in order to view them.
A valid complaint -- most websites should work with Javascript disabled, and noscript proves this. (Though, ironically... isn't noscript, as a Firefox extension, going to be at least partly written in Javascript?)
Also: How does replacing this with a Javascript desktop application improve things? At least the browser tries to sandbox things.
I don't trust my browser to protect me, and I resent having to switch to my virtual machine to browse,
Paranoid much?
But then, if you were to download a Javascript application, wouldn't you run that in a virtual machine, too?
always having that notion that my virtual machine is probably a pox ridden compromised bit bucket that I should really empty at least once a week.
So you're knowledgeable enough to be afraid of scripted web pages, but not enough to use Noscript, and certainly not enough to apply that same paranoia to an application you would download and run with full privileges.
And you're knowledgeable enough to operate a VM, but not to know about its snapshot capability, with which you could get a blank slate every boot.
Yeah, it only does exactly what I'd expect, in a fairly predictable way.
scope for eval'd code,
Eh, maybe. I'm letting this one slide because I can't remember the last time I used eval directly.
the hoops you have to jump through to make "private" functions and variables, etc.
I'd call that a feature. If you're relying on the language to make something "private", you're Doing It Wrong.
I also have a strong bias against untyped languages
Thanks for admitting that -- but this is a bias, and it's also not, by itself, justification for calling a language "bad".
those whose syntactical correctness you can only test by running it with complete code coverage.
I'm skeptical of this -- if you said "correctness", I'd agree, but that is true everywhere. Syntax? If you're not using eval, isn't parsing it enough to show syntactical correctness?
Even tools like jslint are miserable compared to the compile errors, warnings and other static analysis info you get from a well tooled, typed, compiled language.
This is, again, a matter of opinion.
I am of the opinion that compile errors and warnings are, ultimately, a kind of unit test. In particular, typing is a kind of unit test -- you are saying, "This method should only receive arguments of this type." It's just a very limited and highly specialized kind of test, which becomes irrelevant when you're already testing "This object should behave in this way."
These are also unrelated to it being "compiled" or not, which is ultimately an implementation detail. I find it much harder to learn a language without an interactive prompt.
On at least part of this last part, Brendan Eich agrees with me, although the rest of the world managed to convince him it didn't belong in Ecmascript.
Following your link, I found this snippet especially enlightening:
We’d like to be flexible about this and not make things painfully static in a fixed way like Java does.
It's also a stunningly fluff article, at least that page of it.
If you do know what you're doing with threads, I'll grant that you can mostly avoid making things worse than unthreaded code. But I'm sorry, I don't buy that threading makes things simpler -- race conditions, deadlocks, corruption due to forgetting to lock, synchronization in general is a bitch.
Now, if you mean better performing code, I agree -- if you've got multiple cores. Even then, processes are generally a better model -- and certainly in an imperative Algol-derivative like Javascript, it's going to be much simpler to go with some form of cooperative multitasking.
I actually wish JavaScript and other client-side browser scripting would be done away with completely,
Why?
JS is not a particularly 'good' language.
People who say this very often don't know Javascript well at all. It's Lisp in C's clothing. It's actually a surprisingly elegant language -- it has a few warts, but they are almost certainly not what you're thinking of.
A read-only file system is no different conceptually from a number of very simple data structures.
That's true of any filesystem, really -- it's just a data structure that happens to live on disk.
I don't really want to focus this on filesystem versus no-filesystem. That's just one small aspect of the discussion really. And I'm not terribly passionate either way about it.
My point is that the filesystem is a perfect example of something that I think doesn't need to be reinvented in this case, especially for the browser.
When I was young, I kept wanting to just throw everything away and do it from scratch thinking I could do it better. But really it was because I couldn't be bothered to understand it.
I don't think that's quite why I did, I think it's because I would start to understand it, and I'd see hack upon hack upon hack. For example, the advantages of actually forking a separate process, with its own memory space (even if it's COW'd), in order to make a more robust/secure app, spoke to me of the inherent insecurity and instability in the programming models used -- threads should work fine, if you write flawless code. I think that was my thinking.
As I got older I pitied people who wouldn't just accept that some models are proven and time tested, and it is valuable to learn from them.
That's about where I am now. Well, some of both.
I know enough about Unix to see a lot of flaws. You have to look no farther than some of the ext4/btrfs debates, which revive some of the old XFS debates, which also resurfaced during Reiser4 develompent, something as simple as:
If writes are ordered, you can count something like this working:
However, if writes are not ordered, you have to do something more like this:
echo foo > some_file.tmp fsync some_file.tmp #pseudocode, but you see the point. mv some_file.tmp some_file
Now, undordered writes allow some significant performance optimizations. On the other hand, having to sync like that undermines a lot of them -- that's a performance killer if you're doing it hundreds of times during package installation, and really, the entire package installation should be a single transaction. No need to write it to the disc, or even allocate the needed space, until you're ready to commit.
I mean, consider even a ton of sequential updates to that same file. A smart filesystem will buffer writes, and if you change/delete the file before it's written, only the final version is written. Delete a file before it's written, and it'll never touch disk. But sync it, and it has to touch disk.
So I'm not attached to Unix in general, though I'd usually much rather see an incremental improvement to that model than scrapping it entirely. My point here is rather, is this a priority, and will it actually give better results than the existing models? Especially when you've got a significant investment in code -- already, with Chrome, in the case of the desktop versions of the browser, and extensions that should work in both?
Plenty of Javas that don't require a filesystem already.
Can any of them behave as an applet in a web browser? I know of only two that do a decent job of that, and both are forks of the original Sun code.
seriously why would I want Java on a web device? Maybe if this was 1999, but I'm declaring Java web applets officially dead.
Not entirely. And I'm sorry, but as much as I dislike Java applets, I dislike Flash that much more.
JRuby is pretty mature, and can target applets. That alone is a reason to keep Java alive -- it's a non-Microsoft way to run Ruby in any browser that has Java installed, or distribute a Ruby app that can run in a
Fair enough, but the point is, it's not going to be particularly hard on the video card (especially once I turned vsync on), and I'm sorry, but I should be able to peg a CPU at 100% without it overheating itself to death.
Yeah, great, except disabling SpeedStep kills battery life and otherwise sucks power.
I don't mind my laptop throttling itself when I'm not using it. My current Dell (XPS M1530) throttles itself to 800 mhz when it overheats because I'm doing something strenuous -- like, I don't know, Duke Nukem 3D.
The idea can be taken to extremes, but how many of todays Perl and PHP website scripting security issues would evaporate if the authors were forced to write in a less flexible language that took a few moments to actually compile before being enabled?
Not nearly as many security issues as we'd gain from, I don't know, buffer overflows and other whole classes of vulnerabilities which simply don't exist in Perl, PHP, Python, Ruby, even Java code.
Slashdot Mirror
I think the difference here is that Comcast most likely has something about this in their contract -- so users have already agreed to it.
Also, what networks do you have the right to set up a resolver for? Comcast isn't technically "intercepting" anything -- these are requests going directly to their nameservers, that they then decide what to do with.
Me, I'm using them for the performance boost. I've already got a local cache in the form of dnsmasq, and of course, OSes and browsers probably do some caching of their own. But that initial lookup, I'm getting on the order of 150 ms from my ISP's DNS, and about 30 from Google, for the same query.
RTFA:
Google Public DNS stores two sets of logs: temporary and permanent. The temporary logs store the full IP address of the machine you're using. We have to do this so that we can spot potentially bad things like DDoS attacks and so we can fix problems, such as particular domains not showing up for specific users.
We delete these temporary logs within 24 to 48 hours.
In the permanent logs, we don't keep personally identifiable information or IP information. We do keep some location information (at the city/metro level) so that we can conduct debugging, analyze abuse phenomena and improve the Google Public DNS prefetching feature. We don't correlate or combine your information from these logs with any other log data that Google might have about your use of other services, such as data from Web Search and data from advertising on the Google content network. After keeping this data for two weeks, we randomly sample a small subset for permanent storage.
So in other words, for less than two days, their DNS log, and nothing else, will know that a particular request was made from a particular IP. Other than that, they'll know that someone from your ISP, or perhaps from your whole fscking city, made that request -- maybe. I'm guessing they'll be looking at overall trends.
Except in this case, they claim your IP will be gone from their logs in 24 hours, and it'll never be associated with anything else you do at Google.
My guess is, they want broad statistics like the most popular domains visited, maybe even traffic patterns of which domains people tend to go to after which other domains.
So you're right, the motives are quite transparent. Except in this case, I have no idea why I wouldn't want to participate. It's likely to be a hell of a lot more responsive than my ISP's DNS.
everything resolves to Google's proxies.
Really?
You, sir, are a liar.
Cue *whoosh* in 3..2.. actually, I still don't get it. Either you're trolling because you hate Google, or there's some obscure joke that I still don't understand. I really don't get how your list of crap it requires (most of which doesn't exist or doesn't apply to DNS) is funny -- are Google known for requiring random stuff like that?
I mean, they don't even touch NX:
That's more than you can say for most ISP-level resolvers.
So not only as memorizable, but explicitly public, whereas 4.2.2.2 and 4.2.2.1 are both technically being abused when you do that.
That's a bit like saying, if you need to write a program, someone has failed.
Now, if you need to be in the commandline to do something which an ordinary user should be able to do, for which there is a sane GUI equivalent, I agree -- that shouldn't happen.
However, there are and always will be things which are easier to do with a commandline, and things which can't really be expressed elsewhere. The use of pipes alone warrants that.
A fun example would be taking a disk image, checksumming it while compressing it lightly and sending it through an encrypted tunnel to a server, as with light enough encryption, this will actually be faster than sending it unencrypted -- especially if the destination drive is slower/busier than the source drive... then, when it's done, transfer the checksum to the server and have the server decompress the image while verifying the checksum, then immediately re-compressing it with much heavier compression, taking several hours...
You could argue that specific parts of this could be done better -- maybe I should checksum the compressed file so I know sooner. Then again, my way means I'm also checking the compression itself -- it means I absolutely am getting out of the other end the same thing that was on disk. You could also argue that I should bundle all of this into a piece of GUI software designed for taking disk images -- debatable, but I can go with that.
But the fact that I need the commandline to do that now isn't a bug, it's a missing feature. In this case, the commandline is almost acting as a kind of software development -- and it is, after all, Turing-complete.
I'd argue that if you need a GUI for something, that's also a failure. GUIs aren't reliably or easily scriptable, and the concept of pipes doesn't really apply. The above procedure would work, if the GUI had been developed with it in mind -- but it'd have to be a very specific GUI, whereas on the commandline, the compression tools, checksum tools, imaging tools, and encrypted tunnel, are all completely independent and generic -- the same compression tool that I might use to unpack a tarball will also handle a disk image. The same imaging tool which could create a file on an external hard drive can also stream the image over the Internet -- all without knowing anything at all about either of them.
Well, back in the day, it would've been 'man cdrecord', which kind of makes sense. I honestly don't remember how I learned about cdrecord, or how I now know it's been renamed to wodim.
In all honesty, I suspect us Linux users have some sort of telepathic network...
However, trying some of the other questions gives some useful responses:
gives me k3b. Knowing that it's a KDE program, I might then look in the menus to see if it's a GUI program. It is, so I'm done.
houghi points the way to another possible answer. Personally, I'd Google for linux burn cd commandline -- the tutorials returned are out of date, but still work. 'man cdrecord' doesn't give me anything, but 'which cdrecord' tells me it exists, and 'ls -lh `which cdrecord`' tells me it's wodim. So, 'man wodim' gives me the most relevant, though least userfriendly, documentation.
Note, none of this is at the expense of the fact that when I pop in a blank CD, I do get a GUI popup that lets me point-and-click to burn a CD. Since I'm on KDE, this probably leads to k3b, though I haven't used it in awhile.
Well man just confused me more than anything else.... just listing out a whole bunch of switches with some description of what they do that itself doesn't actually mean anything to me, isn't enough.
As a newbie, I remember man actually being useful, sometimes. First, read the name and the description -- these will generally tell you what the command does. In general, if you don't understand at least the name, you don't need to use that program -- for example:
gcc - GNU project C and C++ compiler
If you know what C and C++ are, and what a compiler is, that makes sense. If you don't know what they are, do you need to be using gcc at all?
Once you've got that, usually the synopsis will give you an idea of how it should be used, and what options to look at. If not, look for the examples.
And try info, not just man. It takes just a bit more effort to learn info, and you'd be much better off finding some sort of web-based info browser, but if the program does have an info page, that's likely to be much better organized and easier to understand.
At least, I think that's what worked for me. I actually learned how to use things like gcc and tar from man and info, and I didn't find it particularly difficult.
On the other hand, I was 15, so I'm not really sure how I did it, and it's possible 15-year-olds are just better at learning these things, when motivated.
Google reveals a lot of very helpful and well-written newbie guides though. Perhaps the best of those should be adapted and built-in to the documentation shipping with new distros?
I'd argue they should be mirrored, perhaps absorbed into version control and/or the wiki of the project in question, but I don't see how including them on the CD is that helpful. What would be much more helpful are some meta-tutorials, like how to Google intelligently, how to find the project mailing list -- or failing that, an email address of someone responsible -- and how to ask smart questions -- though it might be easier to start here.
The reason is that no distro could ever include every possible tutorial, or keep them entirely up to date, though it would still be useful to try. It would be much more useful to train users to find the best possible documentation, and when that fails them, ask the best possible questions.
...but a bad analogy.
You can also run all of Windows 7 through a disassembler and you can make changes to your own system with a hex editor editing DLL libraries by hand. That's nearly the same kind of "documentation" and "openness" as far as most users are concerned...
Well, most users won't be able to do either, it's true. But if they actually wanted to make an effort, the learning curve for editing source code is far less.
It's also worth mentioning that the open-ness does, in fact, have visible results. One example is an open bug tracker, which you won't often find on a closed source project -- you can actually submit a bug and watch developers handle it (or ignore it). Another example is the ability to fork a project and add features -- the fact that individual users can't do it doesn't mean they can't reap the rewards when other developers do. A good example here might be Iron, a fork of the Google Chrome browser.
Documentation absolutely is important, and there are large gaps. We do have some of the important bits -- man pages, plenty of stuff on Google, and the README and HACKING documents provided with source code, for those who actually want to make changes.
But then, plenty of people do find sufficient documentation to develop an understanding. You say "none of these exist", but the sheer number of contributors to the Linux kernel should be evidence that they do, to some extent.
I can access help files with a mouse click, too, where it makes sense.
For comparison, open up a Terminal in Mac OS X, and tell me what you find for documentation. In fact, I dare you -- try the same with start->run->cmd on Windows.
If you're already in a commandline environment, man makes sense, and Google makes sense as a way to find out about man. I know of no OS which provides point-and-click help for the commandline, nor can I think of a sane way to do it.
If someone left the hydrant running, does that make the water yours to take? No.
In other words: Better to let the water drain away, and go to waste?
Is that really what you're advocating?
SETI@HOME is doing intense math calculations using as much CPU as it can. Starry Screen Server is not.
It sounds as though you're arguing that SETI uses more power. I was replying to a post which claimed that doesn't matter at all. That's what I'm disputing here.
who to allow? Even fortune 500 are getting compromised left and right.
I think you're being a bit overly-dramatic, but to answer your question, allow the ones you want to. You still get the added benefit that not every Slashdotted article or Google search is a potential vulnerability.
My paranoia is justified I think.
I really don't agree. If you run a decent browser, and keep it patched, it just doesn't seem likely to me. Besides, all you're doing is adding another layer -- if you can't keep your browser patched/secured, what makes you think you can do the same to a VM? They're both just sandboxes.
Besides, if you're willing to go to those extremes, might I suggest a sandboxing browser? On Linux, Chrome seems to be chrooting parts of itself, thus a Javascript vulnerability would only affect one or two tabs, and would need to exploit an additional Linux vulnerability to reach outside of that.
I just hate the thought of becoming the cause of another annoyance in a few thousand people's day as they click delete on the spam my machine sent them.
Good for you! That is admirable.
I'm just questioning whether your approach is warranted. As an example, wouldn't it make more sense to install a firewall -- best way would be as a separate machine, maybe configure your router, etc -- to both block outbound SMTP, and notify you if anything tries?
In other words, be scientific about it. Instead of getting paranoid by reading a lot of security research, actually find out whether either your VM or your host has become a "pox riddencompromised bit bucket", or how often that happens.
It isn't that he was using more, or even less, electricity by running SETI@Home.
Really?
The fact that he was using government electricity for non-governmental purposes is the problem. It is no different than hooking up a hose to a county fire hydrant to fill your personal swimming pool. You benefit, they pay.
Suppose someone left that hydrant running?
If he was using more electricity, you have a point. If he was using less, I really don't see the problem -- and I'm including here the question of whether they were on when they shouldn't be.
Most of today apps use JS in browser and something other on server. This is BAD, no matter how cool JS itself is.
Why is this bad?
I mean, I don't entirely disagree, but it seems a minor issue, really. After all, unless you're using CouchDB, your database queries are written in some query language (probably SQL), which is entirely different than the language your server-side app is developed in.
As browser is becoming a full-fledged platform, it is screaming for support of other languages along side with JS.
And some browsers support this. There are also other ways of doing it -- for example, JRuby as an applet, or various Silverlight bastardizations.
When I talk about an object oriented programming language I'm referring to a language that allows you to use the concepts of OOP in a *natural* and *homogeneous* way.
Please provide an example of how Javascript doesn't do this.
I'm aware that it isn't completely homogeneous in the same way that, say, Ruby is. I challenge you to show me an example of this that actually matters.
I don't want to write a library and helper methods to write an OO program, I want to use the language.
So when you write C++, do you never use the std namespace? When you write Perl, do you completely ignore the existence of CPAN?
People have already written libraries that implement many of the ideas of "traditional" OOP, though if you talk to the person who actually coined the term, most of those "traditional" ideas really aren't.
I think it speaks to the power of a language when whole paradigms like that can be written as libraries. It means that the language is multiparadigm without even trying. And it's always nice to see something you'd think of as a core language feature, even a keyword, but it's possible to express it naturally as library code.
It's OK if it doesn't has classes, and therefore inheritance does not have a place in Javascript,
This is a non-sequitur. Javascript is built on prototypical inheritance, which does not rely on classes.
I'm guessing you found that "private" page -- and enforced-private stuff is not a requirement of OOP, by the way -- but you probably found it here, right? Shortly after that link is another -- this explanation of inheritance in Javascript.
just stop trying to force it to be something that it was not meant to be (that is a general purpose language to write medium to large scale applications).
The fact that it wasn't "meant" to be isn't entirely relevant. It does explain some of the problems we see with it -- I certainly won't claim it's perfect -- but can you explain why Javascript isn't suitable for medium to large scale applications?
Oh, I like xml...
I don't. Think about it -- every opening tag must have a corresponding closing tag, which is at least as long as the opening tag name. I mean, I could pretty easily rant about stuff like that -- you could pretty easily make a much more readable markup language, and people have.
But really, just look at JSON or YAML sometime -- they are much better at representing structured data -- they're smaller, lighter, and easier for humans to edit and understand. XML is good for markup, but even here, tools like markdown tend to be better, at least at being human-editable.
"checked" could still have been 0/1 even as a string, having a whole word seems longwinded, it isn't like web designers don't know what boolean is.
Actually, yes, it would've been annoying as hell to have to look that up every time. I know I'd be wondering if that is in fact a boolean, or if it's a count of some kind -- what would it mean to set checked=2?
Never mind that not all programming languages use 0 and 1 as boolean values. The better ones have a separate concept of true and false.
Now, maybe checked='checked' is a bad idea, and it should've been checked='true', but wasting an extra few characters in something that's going to be gzipped anyway, where you're already automatically wasting a ton of characters on every document just by using closing tags?
Go try Haml. Actually learn it and use it for a few pages. See if you don't like working with it a lot better than raw HTML -- or XML, even.
ID could have been reused for names automatically with no issues. IDs have no real requirement to be unique, could have had them replace classes as well with no issues.
document.getElementById is a lot nicer when you have a unique ID.
Yes, IDs do have a requirement to be unique. Try running your document without unique IDs through the W3C Validator, see what you get.
And no, you can't re-use IDs as names, as then you can't have multiple forms on the page with duplicate names. That is, right now, I can have two separate forms which submit to the same place, with mostly different options but some overlap -- say, "search" and "advanced search". Or I could have forms that submit to completely different servers, and there happens to be some overlap of field names.
So the only thing you're left with is re-using classes as names. That doesn't work either, because you can have multiple classes per form element (what would that mean?), and it also means that the behavior of the form is now tightly coupled to its visual representation.
That is, say you had a bright read style called "urgent". And say you had a form with a checkbox called "urgent". Can you see why it might be confusing if you had some other form element you wanted to style as urgent?
Now, you could make a valid case that if you're using a nice library like jQuery, there isn't really an advantage to IDs -- you could just use classes for everything, with a convention that certain classes be unique. I'd disagree -- the fact that IDs are unique, and that you're applying them to things which actually are guaranteed to be unique on a page, gives you a very simple tool (any HTML validator will do) to ensure that you don't have any duplicate IDs.
the way css styles are applied is strange though that may be css' fault.
Citation needed.
It seems to me that the biggest issue with CSS is browser implementation. Easily 90% of that goes away if you stop supporting IE. The rest of it is useful if you
And people use it. Unless webpages are all div/span tags with a link to the css then people are using html for formatting. (yes, even header tags count since they change font sizes)
*facepalm*
If you use header tags just to change the font size, then sure. Maybe.
But that's not the point, and it's also not necessarily what happens. Just
Do away with client side browser scripting entirely and replace it with applications written in Javascript.
Why?
I mean, the main reason people write client side browser applications isn't JavaScript, it's that they're browser applications.
I don't like the requirement that I have to allow most websites to run essentially arbitrary code on my machine in order to view them.
A valid complaint -- most websites should work with Javascript disabled, and noscript proves this. (Though, ironically... isn't noscript, as a Firefox extension, going to be at least partly written in Javascript?)
Also: How does replacing this with a Javascript desktop application improve things? At least the browser tries to sandbox things.
I don't trust my browser to protect me, and I resent having to switch to my virtual machine to browse,
Paranoid much?
But then, if you were to download a Javascript application, wouldn't you run that in a virtual machine, too?
always having that notion that my virtual machine is probably a pox ridden compromised bit bucket that I should really empty at least once a week.
So you're knowledgeable enough to be afraid of scripted web pages, but not enough to use Noscript, and certainly not enough to apply that same paranoia to an application you would download and run with full privileges.
And you're knowledgeable enough to operate a VM, but not to know about its snapshot capability, with which you could get a blank slate every boot.
I'm not sure how to put this nicely, but...
A little knowledge is a dangerous thing.
There's so much broken - scope,
Example, please.
the this keyword,
Yeah, it only does exactly what I'd expect, in a fairly predictable way.
scope for eval'd code,
Eh, maybe. I'm letting this one slide because I can't remember the last time I used eval directly.
the hoops you have to jump through to make "private" functions and variables, etc.
I'd call that a feature. If you're relying on the language to make something "private", you're Doing It Wrong.
I also have a strong bias against untyped languages
Thanks for admitting that -- but this is a bias, and it's also not, by itself, justification for calling a language "bad".
those whose syntactical correctness you can only test by running it with complete code coverage.
I'm skeptical of this -- if you said "correctness", I'd agree, but that is true everywhere. Syntax? If you're not using eval, isn't parsing it enough to show syntactical correctness?
Even tools like jslint are miserable compared to the compile errors, warnings and other static analysis info you get from a well tooled, typed, compiled language.
This is, again, a matter of opinion.
I am of the opinion that compile errors and warnings are, ultimately, a kind of unit test. In particular, typing is a kind of unit test -- you are saying, "This method should only receive arguments of this type." It's just a very limited and highly specialized kind of test, which becomes irrelevant when you're already testing "This object should behave in this way."
These are also unrelated to it being "compiled" or not, which is ultimately an implementation detail. I find it much harder to learn a language without an interactive prompt.
On at least part of this last part, Brendan Eich agrees with me, although the rest of the world managed to convince him it didn't belong in Ecmascript.
Following your link, I found this snippet especially enlightening:
We’d like to be flexible about this and not make things painfully static in a fixed way like Java does.
It's also a stunningly fluff article, at least that page of it.
Bullshit.
If you do know what you're doing with threads, I'll grant that you can mostly avoid making things worse than unthreaded code. But I'm sorry, I don't buy that threading makes things simpler -- race conditions, deadlocks, corruption due to forgetting to lock, synchronization in general is a bitch.
Now, if you mean better performing code, I agree -- if you've got multiple cores. Even then, processes are generally a better model -- and certainly in an imperative Algol-derivative like Javascript, it's going to be much simpler to go with some form of cooperative multitasking.
I actually wish JavaScript and other client-side browser scripting would be done away with completely,
Why?
JS is not a particularly 'good' language.
People who say this very often don't know Javascript well at all. It's Lisp in C's clothing. It's actually a surprisingly elegant language -- it has a few warts, but they are almost certainly not what you're thinking of.
Google Douglas Crockford.
A read-only file system is no different conceptually from a number of very simple data structures.
That's true of any filesystem, really -- it's just a data structure that happens to live on disk.
I don't really want to focus this on filesystem versus no-filesystem. That's just one small aspect of the discussion really. And I'm not terribly passionate either way about it.
My point is that the filesystem is a perfect example of something that I think doesn't need to be reinvented in this case, especially for the browser.
When I was young, I kept wanting to just throw everything away and do it from scratch thinking I could do it better. But really it was because I couldn't be bothered to understand it.
I don't think that's quite why I did, I think it's because I would start to understand it, and I'd see hack upon hack upon hack. For example, the advantages of actually forking a separate process, with its own memory space (even if it's COW'd), in order to make a more robust/secure app, spoke to me of the inherent insecurity and instability in the programming models used -- threads should work fine, if you write flawless code. I think that was my thinking.
As I got older I pitied people who wouldn't just accept that some models are proven and time tested, and it is valuable to learn from them.
That's about where I am now. Well, some of both.
I know enough about Unix to see a lot of flaws. You have to look no farther than some of the ext4/btrfs debates, which revive some of the old XFS debates, which also resurfaced during Reiser4 develompent, something as simple as:
If writes are ordered, you can count something like this working:
However, if writes are not ordered, you have to do something more like this:
Now, undordered writes allow some significant performance optimizations. On the other hand, having to sync like that undermines a lot of them -- that's a performance killer if you're doing it hundreds of times during package installation, and really, the entire package installation should be a single transaction. No need to write it to the disc, or even allocate the needed space, until you're ready to commit.
I mean, consider even a ton of sequential updates to that same file. A smart filesystem will buffer writes, and if you change/delete the file before it's written, only the final version is written. Delete a file before it's written, and it'll never touch disk. But sync it, and it has to touch disk.
So I'm not attached to Unix in general, though I'd usually much rather see an incremental improvement to that model than scrapping it entirely. My point here is rather, is this a priority, and will it actually give better results than the existing models? Especially when you've got a significant investment in code -- already, with Chrome, in the case of the desktop versions of the browser, and extensions that should work in both?
Plenty of Javas that don't require a filesystem already.
Can any of them behave as an applet in a web browser? I know of only two that do a decent job of that, and both are forks of the original Sun code.
seriously why would I want Java on a web device? Maybe if this was 1999, but I'm declaring Java web applets officially dead.
Not entirely. And I'm sorry, but as much as I dislike Java applets, I dislike Flash that much more.
JRuby is pretty mature, and can target applets. That alone is a reason to keep Java alive -- it's a non-Microsoft way to run Ruby in any browser that has Java installed, or distribute a Ruby app that can run in a
Fair enough, but the point is, it's not going to be particularly hard on the video card (especially once I turned vsync on), and I'm sorry, but I should be able to peg a CPU at 100% without it overheating itself to death.
Yeah, great, except disabling SpeedStep kills battery life and otherwise sucks power.
I don't mind my laptop throttling itself when I'm not using it. My current Dell (XPS M1530) throttles itself to 800 mhz when it overheats because I'm doing something strenuous -- like, I don't know, Duke Nukem 3D.
The idea can be taken to extremes, but how many of todays Perl and PHP website scripting security issues would evaporate if the authors were forced to write in a less flexible language that took a few moments to actually compile before being enabled?
Not nearly as many security issues as we'd gain from, I don't know, buffer overflows and other whole classes of vulnerabilities which simply don't exist in Perl, PHP, Python, Ruby, even Java code.