> Snow is just snow. 99% of the time its a nice fluffy powder.
Good snow is a nice fluffy powder, but good snow only forms when it's actually cold out.
The stuff that forms at temperatures close to thirty is another thing. Personally, I call this stuff "slush" and think it's too warm and melty, but people who dislike winter tend to call it "snow" and complain that it's "too cold". Whatever you call it, it adheres to absolutely everything.
> Why aren't they using sloped lenses and hoods for these? > Essentially putting blinders on them with no bottom so > that snow isn't allowed to collect inside the enclosure?
Do you live in Georgia?
Fine, I'll explain the obvious. Snow doesn't behave quite the same as confetti. Snow is perfectly capable of being blown under any shape of hood you care to devise, adhering several inches thick to the front/underside of a negatively sloped surface, and staying there until spring.
Really the only way to ensure that snow doesn't stick to something is to keep that thing heated at least a few degrees above freezing. (Or just keep the thing indoors, but in the case of a traffic light you generally want to hang it over a traffic intersection, which is typically outdoors.)
However, the heaters wouldn't necessarily have to run all the time, only when there's snow. Determining how to set it up so that they only run when necessary is left as an exercise.
> Of all the proposals that came out of the ROAD/IPng > process the SIPP proposal -- which is what IPv6 is > -- was the most minimal change.
If the other proposals were even further removed from IPv4, then everyone involved in the process was an idiot.
Do you want evidence that IPv6 tried to change too much? Here's some: in a couple of days it'll be 2010, and pretty much everything is still running on IPv4 more or less exclusively. At this point there is no reason to believe IPv6 will *ever* be widely adopted, in the sense of actually replacing IPv4.
IPv6 hasn't "made it" for a variety of reasons, and they all boil down to this: too many changes, and not enough backward compatibility.
For one thing, an IPv4 address is not automatically a valid IPv6 address, and it should have been. The next-gen address space should have been constructed in a way that would make it easy and natural to reserve corresponding IPv6 addresses for all existing IPv4 addresses and allow the software to automatically make the translation. The most obvious way to do that is to divide the 64-bit address into four 16-bit words, and if the most significant halves of all four words are empty, then it belongs to the same system that has the corresponding 32-bit IPv4 address. We could even have express the new addresses in human-readable dotted-quad notation, at which point the rule would be, if all four numbers are less than 256, then it's also valid as an IPv4 address that points to the same system. For backward compatibility, systems using the new protocol could have been programmed to "fall back" TCP connection attempts to the old protocol when contact cannot be established, but only if both systems have addresses that are valid for IPv4 (i.e., no bits set in the top half of any of the four sixteen-bit words). Updated systems could have been talking to one another in the new protocol and still talking to legacy systems using the old protocol, without any extra work at all on the system administrator's part. Network administrators wouldn't even have had to *learn* anything new. DNS wouldn't have had to change significantly (except to allow numbers larger than 255).
But no, if you want to use IPv6, you have to learn a whole new addressing system, assign separate IPv6 addresses to each system that don't correspond in any meaningful way to the IPv4 ones, have separate DNS records for the IPv6 addresses of each and every system... Why is a network administrator who has IPv4 addresses available going to go to the extra effort? Where's the benefit? And if the guys who run established networks don't adopt IPv6, then there's no incentive for anyone else either, because you can't use it to connect to established network services.
And all that nonsense about trying to replace DHCP with mechanisms built into IPv6, that's just gravy on the cake. Why on *earth* did anyone think that was going to fly?
It's like the IPv6 designers had never heard of inertia.
> For RSS, for example, I can't say I care about it.
Indeed. I have a podcatcher, which reads the feeds and downloads any new content automatically on a cron job while I sleep, so why would I need RSS support in the browser? Just so I can have "Live Bookmarks"? Meh. Not important.
Having said that, Chrome is at this point still missing some features that really prevent me from using it on a regular basis.
Number one for me is the ability to disable page-specified colors and browse using my own preferred colors. I know most people would never use this, but for me it's an accessibility requirement, because the blinding white backgrounds that are so popular on the web are just way too much. (My eyes are unusually sensitive to light. It does have its upsides. I can read comfortably in light that would have some people stumbling around trying to find a lightswitch.) I have to have low-contrast colors on the screen, and the background color needs to be the darker one. Otherwise I can only browse for a few minutes at a time, squinting, and then I get a headache and have to quit.
I also don't want to do without bookmark keywords, which have been built into all Gecko-based browsers for over a decade. The ability to set a minimum font size is nice, especially if you've got your resolution cranked up pretty high.
There are also some quite useful features that are supplied in Firefox by popular extensions, which appear to be thus far missing for Chrome unless I'm missing something. Probably the most important of these is FlashBlock. I can't imagine how anyone can live without FlashBlock, except by not having Flash installed at all. Beyond that, I am also unwilling to use a browser that doesn't have Nuke Anything Enhanced or the equivalent functionality. ImageZoom is really nice too. User Agent Switcher occasionally comes in handy, as well. Oh, and the Web Developer toolbar is very handy, not just for web development but also for the way it lets you quickly and conveniently turn certain options on and off (client-side scripts, redirects, page colors,...) And if you're trying to learn an Asian language, rikaichan is helpful.
As for the speed, maybe I'm looking at the wrong sites (I tested the Order of the Stick, How to Spot a Psychopath, Life at Patience Corners, and Perlmonks. ), but I don't see a big difference in speed between Firefox and Chrome. I've done a couple of side-by-side comparison (time how long a page takes to load in the one browser, then time the same page in the other browser), and while Chrome did come out slightly ahead, it was only about a 20% difference, well below what I'd have been likely to notice if I hadn't been timing it. The lack of bookmark keywords alone would cost me more time than the 20% faster page loading would save me. Startup time's noticeably faster for Chrome, but since I normally only restart my browser after power outages and browser upgrades (and tend to delay the latter until I'm restarting anyway due to the former), that's not really an important issue for me. YMMV.
Yeah, but Firefox has that too (optionally). It's called FlashBlock, and what really rocks is that you can over-ride it and enable Flash just for a specific piece of content (e.g., an embedded video on your friend's blog) without turning it on for every stupid Flash thing on the whole web, or even the whole page.
Believe me, if it weren't for FlashBlock, I wouldn't have Flash installed.
> I'd actually like for Windows to start having a > repository of software that it can install stuff,
Oh, like Debian.
> without admin permissions.
Actually, I think there should be a specific permission, "install software from approved repositories", which the sysadmin can grant to any user he chooses. (For home users who stick withe OEM setup, the OEM would be the sysadmin, so they could set it up so that the out-of-the-box user account has this permission if they think that's appropriate.)
> Yeah, I know everyone just winced and thought 'monopoly power',
It wouldn't have to be handled that way.
> but it should be an entirely free system to add new repositories. > Simply a requirement that you be an actual identifiable person or company,
No, that would be bad, because Microsoft would be in the position to decide who's a real person or company, which immediately raises the spectre of the monopoly abuse scenario.
The correct solution is that the system administrator is responsible for deciding which repositories are approved and which are not. Anyone (well, anyone with an internet-connected server and adequate bandwidth) can run a repository, but users won't be installing software from it unless the sysadmin puts the repository on the approved list. Again, if it's an OEM setup, the OEM is the de facto sysadmin (unless the user starts making administrative changes, at which point they take on the sysadmin role themselves).
Microsoft themselves should run at *least* three different repositories: one for just Windows stuff, one for other (gratis) Microsoft software, and one for third-party (gratis) software that they approve and host. These should be offered at install time so that all the sysadmin has to do to approve them is turn on the corresponding checkboxes. (The first one, the Windows repository, should be checked by default.)
So if the sysadmin checks the box for "Microsoft - other free software", then some user finds out they need the Powerpoint Viewer, if the sysadmin gave them the install-from-repositories bit, they can install it without bugging the sysadmin.
The sysadmin should be able to open up the package manager, hit an "add repository" button (which might prompt for an admin password, depending on what kind of account you're logged into when you do this), paste in a URL, click OK, and voila, from now on any user with the install-from-repositories privilege should be able to install any of the software hosted on that repository. So then if OSDN decides to host a repository of open-source software, and if the sysadmin for a given computer adds it, then any user with the install-from-repositories bit set can cause any of the open-source software on the OSDN repository to be installed on the local computer.
For the interface, I'm thinking something similar to Synaptic, but perhaps with a nicer browse interface (larger entries that actually show a description of the package's contents right there in the list). Oh, and the list of packages would be simpler than Debian's, to wit, a particular piece of software would be one package, not twelve, because Windows users don't want to have to figure out which package(s) to select to install the console version of Emacs or the gtk version or the xaw3d version and whether to also include the elisp sources and so on. (Picking between XEmacs and Gnu Emacs is choice enough for Windows users. If they wanted lots of detailed options they'd switch to an OS that has more configurability. In a pinch, advanced users can still go outside the package system and download a more specialized installer or even compile their own.)
Obviously, the software on such repositories would have to come in some kind of standard package format, rather than arbitrary executable self-extracting install wizards as is the current custom. But that's not a big problem. The standard package format *could* include an executable phase, as some of the current package formats for other OS distributions do, as long as it's all standardized so that the package manager can do both install and uninstall fully automatically.
> So then you'd be fine with someone walking up to you and/or > someone you care about at random and killing you and/or them
Of course not. I'd expect the police to investigate that and hopefully prosecute the perpetrator.
But I wouldn't expect the entire nation to shut down for three weeks and then impose severe restrictions on walking, in order to prevent anyone in the future from ever walking up to anyone else.
> Citations are provided as footnotes, and as such are completely unobtrusive.
It's not the footnotes that bother me, it's the phrase {citation needed} repeated in some cases more than fifty times in the space of a three-page article. There is nothing good about this phenomenon.
> I don't agree that you raise the quality of something by adding > loads of pointless articles about non-entities. Wikipedia isn't > designed to be a receptacle for every last fact.
It's designed to be an encyclopedia, a resource people can look to first when they want an introduction to some random topic. That's what an encyclopedia is.
> Personally I believe that once a certain number of articles > of given quality exist there the bar should be raised much > higher in terms of addition and change, to maintain quality. > It's always going to be more damaging to have mistakes and > vandalism then to omit articles about non-entities.
Remember that this is an online repository, not a printed book. If the reader doesn't care about the topic of most of the articles, he doesn't have to flip past them to find the ones he is interested in. The only people who find the articles on obscure topics are those who go *looking* for them.
Now, I agree that it's still important to have quality standards. The articles still need to be decent articles.
But in most cases (barring obvious vanity-article cases) articles shouldn't be excluded simply because "the topic isn't important enough that we really need an article on it". Wikipedia is much more useful than Britannica precisely because it has articles on almost everything, and Britannica's coverage is, by comparison, extremely spotty.
Sounds to me like your worries had a lot more to do with the belt than the shoes. I said running *shoes* through the machine is a minor inconvenience. I didn't say anything about belts.
(Also, why couldn't you stand there at the conveyor, put the shoes and laptop and stuff in a bin, then take off your belt and put that in, holding up your pants with one hand? When your stuff comes out the other end, grab the belt and put it on first, then pick up the rest of your stuff. Annoying and a little embarrassing, sure, but at least your pants wouldn't fall off. Walking across the room without a belt seems like tempting fate, especially if you're shaped like me and wear loose pants.)
> So, the 9/11 hijackers were all dull & depressed?
The 9/11 hijackers didn't need any particular intelligence to do what they did, because at the time our policy in the event of a plane hijacking was to cooperate with the hijackers and given them what they want until the plane is on the ground. Stupid, but that was our policy for decades.
> a large number of people are forced into using outlook
In every single case, when someone is required to use Outlook, there is somebody at their organization who made the decision to require them to use it. So my point stands.
> When was the last time you used seven-year-old software?
> * Linux kernel: 1991
You're using a version 0.something Linux kernel? Really?
> * Vim: 1992, first port to Unix
I don't know enough about Vim to get specific.
> * Firefox: 2003. It's getting close. If you extend this > to the Mozilla suite, then you're in the 1990s easily.
Again, you're using Mozilla 1.5?
> * Bash: 1987
I bet you've upgraded that, too. Otherwise it almost certainly wouldn't work with a modern glibc.
I stand by my original assertion. If an open-source project is so inactive that a seven-year-old version is still current and in widespread use, the danger of a closed-source fork seems unimportant.
> I want an accessory that is worn on your torso (as a vest) and delivers > a paintball-like punch when an in-game bullet strikes your avatar.
Getting punched with a paintball isn't the same thing as getting shot with armor-piercing rounds. Meh. We need better realism than that.
I'm working on a gaming accessory that monitors your in-game situation and, when your character gets shot, actually fires a bullet at the gamer. It's sensitive to the seriousness of the in-game wound, so if your character catches a glancing blow across his thigh from halfway across the game world the real bullet is a low-velocity one and just grazes your thigh, but if your character takes a point-blank shot to the chest you won't be able to keep playing. Patent pending.
The problem with IPv6 is that it tried to do too much all at once, most of it completely unnecessary, and some of it arguably not even a good idea. The only part of it we really can't live without is the increase in address size, which could have been handled much more simply with a lot less other change.
> According to metric prefixes accepted in virtually > every other field, 4096 bytes is 4.1KB
In every other field, it's useful to know how many thousand of something you have.
In computing, however, it is a great deal more useful to know how many 1024-byte kilobytes you have, because space is allocated in power-of-two-sized sectors, so 1024 is either a multiple (two 512-byte sectors) or a factor (a quarter of a 4096-byte sector).
With a 512-byte sector, if I have a bunch of very small (but not zero-size) files and the disk has 128 kilobytes left, I expect to be able to store no more than 256 of my little files in that space. But if some cretinous loser programs the shell to tell me that I have 131 metric "kilobytes", I won't know how much space I really have.
If you want to use metric quantities, use kilobits, megabits, gigabits, and so on (as, indeed, is commonly done when measuring bandwidth). The byte is a power-of-two-based unit, which is what makes it useful for measuring computer storage, because computers do all their arithmetic in binary and for this reason are always going to allocate space (both in volatile memory and on secondary storage) in those terms. It's that way for a reason, and it is going to stay that way.
You'll notice they're not talking about 4000-byte or 40000-bit sectors. That would be dumb.
> A byte can be 10 bits; it's an architecture-specific quantity.
Historically, yes, but not any time recently. Not, for instance, since people started to write software that was portable enough to be compiled for different hardware architectures. If you think codepages and endianness are bad, just *imagine* trying to port your software to an architecture with an exotic byte size! No thanks. Different word sizes and address BUS widths are bad enough.
Yes, at one time long ago, there were other "byte" sizes. But that's reaching pretty far back into the history books. By the time IBM sold their first x86-based "Personal Computer", the entire computing world had fully standardized on the eight-bit byte. DEC, for instance, after dipping their toes in the pool with the PDP-11, finally came fully over to eight-bit bytes with the Vax and thereafter never looked back -- and they were one of the last holdouts.
> People confuse byte and octet all the time, because > popular hardware architectures use an octet as a byte.
Only the popular ones, eh?
Can you name a hardware architecture, for which new hardware has been manufactured within the last quarter of a century, that uses any byte size *other* than eight bits?
In 1950, your assertion would have been technically accurate, albeit pedantic. But today it's just so much anachronistic nonsense. A byte *is* an octet, period.
Ironically, however, a character is no longer necessarily representable in a single byte.
> But many people don't use their tools every day. > I'd say that every single one of us have some tools > that we do use and do like, but we simply don't > need them every day or even every week.
We're talking about Emacs here. It's a text editor. How on earth could you work on a computer for a whole hour, much less a week, without using a text editor?
Yes, obviously, there *are* people who can go a whole week without using a text editor (except for the extremely lame one built into the textarea handling of their web browser), but such people are quite obviously not part of the target market for Emacs. They play Farmville, can't tell the difference between a banner advert and a dialog box, don't know the difference between a firewall and a virus, and have never heard of Slashdot. They print email so they'll have a copy and then delete it so it won't waste space. If they do for some reason need a text editor, they can use Notepad (or more likely they can go running for help to someone like me). Not only do these people exist, they are in the majority.
But that doesn't mean that Emacs doesn't need to exist. Because, you know, some of us *do* actually use our computers for getting actual work done, not just for watching lame YouTube videos and making stupid PowerPoint presentations.
> If you don't want to compute something right away, > wrap it up in a lambda and bind it to a symbol
No, I want it to go ahead and *start* calculating, but I don't want to *wait* for it to finish, until I get to the point of actually needing the result, later. This would be especially useful when loading information from a slow source, such as a remote server. Start it, do your other stuff, and *then* check the result.
It goes along with what I said about threading (or I suppose actual forking would get the job done too).
> Selective lazy evaluation is more of an occasional > syntax convenience for specific problems like streams
Okay, but streams are not exactly an unusual phenomenon. Emacs modules use them for all kinds of things. It would be nice if they were easier to work with.
> I'm honestly curious why it can't just go into > the same kind of masterpiece-maintenance mode > as some of Knuth's projects like Tex.
If you are the sort of person who has to ask this question, you cannot possibly understand the answer. I mean, come on, you're happy using a cut-down piece of junk like mg that doesn't even have a lisp interpreter built in. What kind of text editor doesn't even have a high-level language interpreter built in? You'd spend ten or twenty times as long doing everything, for lack of the ability to easily reprogram the editor for the task at hand.
But I will attempt to answer anyway. The following is a list of features that I have looked for in Emacs and found wanting, things that every text editor *ought* to have, and it's disgraceful that Emacs doesn't have them.
I want lazy evaluation. I want to be able to do this: (setq some-variable (lazy (some-function foo bar))) And then I want the next thing after that to go ahead and be evaluated. I don't want execution to pause and wait for some-function to complete until some computation actually needs the value of some-variable.
I want better threading support, across the board. Just *one* example is that I want Gnus to be checking for new mail in the background every n seconds while I'm reading my mail, and automatically sort the new messages and insert them into the relevant groups, even if that means inserting them into a group I'm currently reading and updating the message list in real time. Gnus is just one example. I want everything in Emacs to work as if the computer is capable of doing more than one thing at a time, because it's not 1982 any more.
I want some equivalent for CPAN.pm, to make module installation easier. While we're copying features from Perl, I also want a reasonable quoting construct for regular expressions so I don't have to quadruple-backslash everything. Perl-like advanced regex features would also be nice.
I want eshell to have pipe and redirection capabilities. Yes, I know I can use a different shell in shell-mode, but I want the ability to use lisp functions too. I want both capabilities, at the same time, in the same shell.
I want cperl-mode to do a better job with complicated regular expressions and qq(strings) and such. I know it's hard, but I want it anyway.
That's just the stuff I can think of off the top of my head, in a hurry because I need to go get ready for work now.
> Will Emacs then update itself and become self-aware? That > ought to put the Emacs vs. VI debate to rest once and for all.
I'm not sure it would make any difference, actually. The whole point of vi is to have an editor that doesn't really let you do anything else except edit text. For vi users, this gives it some kind of theoretical aesthetic purity or something.
The only way to really put the Emacs versus vi debate to rest is to create a version of vi that contains a built-in lisp interpreter compatible with the one Emacs is built on. The other side of things is already covered: Emacs has had viper-mode for a long time. But to set the debate fully to rest it needs to go both ways.
Slashdot Mirror
> Snow is just snow. 99% of the time its a nice fluffy powder.
Good snow is a nice fluffy powder, but good snow only forms when it's actually cold out.
The stuff that forms at temperatures close to thirty is another thing. Personally, I call this stuff "slush" and think it's too warm and melty, but people who dislike winter tend to call it "snow" and complain that it's "too cold". Whatever you call it, it adheres to absolutely everything.
> Why aren't they using sloped lenses and hoods for these?
> Essentially putting blinders on them with no bottom so
> that snow isn't allowed to collect inside the enclosure?
Do you live in Georgia?
Fine, I'll explain the obvious. Snow doesn't behave quite the same as confetti. Snow is perfectly capable of being blown under any shape of hood you care to devise, adhering several inches thick to the front/underside of a negatively sloped surface, and staying there until spring.
Really the only way to ensure that snow doesn't stick to something is to keep that thing heated at least a few degrees above freezing. (Or just keep the thing indoors, but in the case of a traffic light you generally want to hang it over a traffic intersection, which is typically outdoors.)
However, the heaters wouldn't necessarily have to run all the time, only when there's snow. Determining how to set it up so that they only run when necessary is left as an exercise.
> Of all the proposals that came out of the ROAD/IPng
> process the SIPP proposal -- which is what IPv6 is
> -- was the most minimal change.
If the other proposals were even further removed from IPv4, then everyone involved in the process was an idiot.
Do you want evidence that IPv6 tried to change too much? Here's some: in a couple of days it'll be 2010, and pretty much everything is still running on IPv4 more or less exclusively. At this point there is no reason to believe IPv6 will *ever* be widely adopted, in the sense of actually replacing IPv4.
IPv6 hasn't "made it" for a variety of reasons, and they all boil down to this: too many changes, and not enough backward compatibility.
For one thing, an IPv4 address is not automatically a valid IPv6 address, and it should have been. The next-gen address space should have been constructed in a way that would make it easy and natural to reserve corresponding IPv6 addresses for all existing IPv4 addresses and allow the software to automatically make the translation. The most obvious way to do that is to divide the 64-bit address into four 16-bit words, and if the most significant halves of all four words are empty, then it belongs to the same system that has the corresponding 32-bit IPv4 address. We could even have express the new addresses in human-readable dotted-quad notation, at which point the rule would be, if all four numbers are less than 256, then it's also valid as an IPv4 address that points to the same system. For backward compatibility, systems using the new protocol could have been programmed to "fall back" TCP connection attempts to the old protocol when contact cannot be established, but only if both systems have addresses that are valid for IPv4 (i.e., no bits set in the top half of any of the four sixteen-bit words). Updated systems could have been talking to one another in the new protocol and still talking to legacy systems using the old protocol, without any extra work at all on the system administrator's part. Network administrators wouldn't even have had to *learn* anything new. DNS wouldn't have had to change significantly (except to allow numbers larger than 255).
But no, if you want to use IPv6, you have to learn a whole new addressing system, assign separate IPv6 addresses to each system that don't correspond in any meaningful way to the IPv4 ones, have separate DNS records for the IPv6 addresses of each and every system... Why is a network administrator who has IPv4 addresses available going to go to the extra effort? Where's the benefit? And if the guys who run established networks don't adopt IPv6, then there's no incentive for anyone else either, because you can't use it to connect to established network services.
And all that nonsense about trying to replace DHCP with mechanisms built into IPv6, that's just gravy on the cake. Why on *earth* did anyone think that was going to fly?
It's like the IPv6 designers had never heard of inertia.
> 4-bit microcontrollers are still made.
Yes, and they're used in control circuitry for things like washing machines and coffee makers, not for general-purpose programmable computers.
> For RSS, for example, I can't say I care about it.
...) And if you're trying to learn an Asian language, rikaichan is helpful.
Indeed. I have a podcatcher, which reads the feeds and downloads any new content automatically on a cron job while I sleep, so why would I need RSS support in the browser? Just so I can have "Live Bookmarks"? Meh. Not important.
Having said that, Chrome is at this point still missing some features that really prevent me from using it on a regular basis.
Number one for me is the ability to disable page-specified colors and browse using my own preferred colors. I know most people would never use this, but for me it's an accessibility requirement, because the blinding white backgrounds that are so popular on the web are just way too much. (My eyes are unusually sensitive to light. It does have its upsides. I can read comfortably in light that would have some people stumbling around trying to find a lightswitch.) I have to have low-contrast colors on the screen, and the background color needs to be the darker one. Otherwise I can only browse for a few minutes at a time, squinting, and then I get a headache and have to quit.
I also don't want to do without bookmark keywords, which have been built into all Gecko-based browsers for over a decade. The ability to set a minimum font size is nice, especially if you've got your resolution cranked up pretty high.
There are also some quite useful features that are supplied in Firefox by popular extensions, which appear to be thus far missing for Chrome unless I'm missing something. Probably the most important of these is FlashBlock. I can't imagine how anyone can live without FlashBlock, except by not having Flash installed at all. Beyond that, I am also unwilling to use a browser that doesn't have Nuke Anything Enhanced or the equivalent functionality. ImageZoom is really nice too. User Agent Switcher occasionally comes in handy, as well. Oh, and the Web Developer toolbar is very handy, not just for web development but also for the way it lets you quickly and conveniently turn certain options on and off (client-side scripts, redirects, page colors,
As for the speed, maybe I'm looking at the wrong sites (I tested the Order of the Stick, How to Spot a Psychopath, Life at Patience Corners, and Perlmonks. ), but I don't see a big difference in speed between Firefox and Chrome. I've done a couple of side-by-side comparison (time how long a page takes to load in the one browser, then time the same page in the other browser), and while Chrome did come out slightly ahead, it was only about a 20% difference, well below what I'd have been likely to notice if I hadn't been timing it. The lack of bookmark keywords alone would cost me more time than the 20% faster page loading would save me. Startup time's noticeably faster for Chrome, but since I normally only restart my browser after power outages and browser upgrades (and tend to delay the latter until I'm restarting anyway due to the former), that's not really an important issue for me. YMMV.
> I thought flash not working is a feature.
Yeah, but Firefox has that too (optionally). It's called FlashBlock, and what really rocks is that you can over-ride it and enable Flash just for a specific piece of content (e.g., an embedded video on your friend's blog) without turning it on for every stupid Flash thing on the whole web, or even the whole page.
Believe me, if it weren't for FlashBlock, I wouldn't have Flash installed.
> Once it was possible for these things to leak
> onto the Internet, I think they quit doing them.
Then how do you explain the Windows 7 ones?
> I'd actually like for Windows to start having a
> repository of software that it can install stuff,
Oh, like Debian.
> without admin permissions.
Actually, I think there should be a specific permission, "install software from approved repositories", which the sysadmin can grant to any user he chooses. (For home users who stick withe OEM setup, the OEM would be the sysadmin, so they could set it up so that the out-of-the-box user account has this permission if they think that's appropriate.)
> Yeah, I know everyone just winced and thought 'monopoly power',
It wouldn't have to be handled that way.
> but it should be an entirely free system to add new repositories.
> Simply a requirement that you be an actual identifiable person or company,
No, that would be bad, because Microsoft would be in the position to decide who's a real person or company, which immediately raises the spectre of the monopoly abuse scenario.
The correct solution is that the system administrator is responsible for deciding which repositories are approved and which are not. Anyone (well, anyone with an internet-connected server and adequate bandwidth) can run a repository, but users won't be installing software from it unless the sysadmin puts the repository on the approved list. Again, if it's an OEM setup, the OEM is the de facto sysadmin (unless the user starts making administrative changes, at which point they take on the sysadmin role themselves).
Microsoft themselves should run at *least* three different repositories: one for just Windows stuff, one for other (gratis) Microsoft software, and one for third-party (gratis) software that they approve and host. These should be offered at install time so that all the sysadmin has to do to approve them is turn on the corresponding checkboxes. (The first one, the Windows repository, should be checked by default.)
So if the sysadmin checks the box for "Microsoft - other free software", then some user finds out they need the Powerpoint Viewer, if the sysadmin gave them the install-from-repositories bit, they can install it without bugging the sysadmin.
The sysadmin should be able to open up the package manager, hit an "add repository" button (which might prompt for an admin password, depending on what kind of account you're logged into when you do this), paste in a URL, click OK, and voila, from now on any user with the install-from-repositories privilege should be able to install any of the software hosted on that repository. So then if OSDN decides to host a repository of open-source software, and if the sysadmin for a given computer adds it, then any user with the install-from-repositories bit set can cause any of the open-source software on the OSDN repository to be installed on the local computer.
For the interface, I'm thinking something similar to Synaptic, but perhaps with a nicer browse interface (larger entries that actually show a description of the package's contents right there in the list). Oh, and the list of packages would be simpler than Debian's, to wit, a particular piece of software would be one package, not twelve, because Windows users don't want to have to figure out which package(s) to select to install the console version of Emacs or the gtk version or the xaw3d version and whether to also include the elisp sources and so on. (Picking between XEmacs and Gnu Emacs is choice enough for Windows users. If they wanted lots of detailed options they'd switch to an OS that has more configurability. In a pinch, advanced users can still go outside the package system and download a more specialized installer or even compile their own.)
Obviously, the software on such repositories would have to come in some kind of standard package format, rather than arbitrary executable self-extracting install wizards as is the current custom. But that's not a big problem. The standard package format *could* include an executable phase, as some of the current package formats for other OS distributions do, as long as it's all standardized so that the package manager can do both install and uninstall fully automatically.
> So then you'd be fine with someone walking up to you and/or
> someone you care about at random and killing you and/or them
Of course not. I'd expect the police to investigate that and hopefully prosecute the perpetrator.
But I wouldn't expect the entire nation to shut down for three weeks and then impose severe restrictions on walking, in order to prevent anyone in the future from ever walking up to anyone else.
> Citations are provided as footnotes, and as such are completely unobtrusive.
It's not the footnotes that bother me, it's the phrase {citation needed} repeated in some cases more than fifty times in the space of a three-page article. There is nothing good about this phenomenon.
> I don't agree that you raise the quality of something by adding
> loads of pointless articles about non-entities. Wikipedia isn't
> designed to be a receptacle for every last fact.
It's designed to be an encyclopedia, a resource people can look to first when they want an introduction to some random topic. That's what an encyclopedia is.
> Personally I believe that once a certain number of articles
> of given quality exist there the bar should be raised much
> higher in terms of addition and change, to maintain quality.
> It's always going to be more damaging to have mistakes and
> vandalism then to omit articles about non-entities.
Remember that this is an online repository, not a printed book. If the reader doesn't care about the topic of most of the articles, he doesn't have to flip past them to find the ones he is interested in. The only people who find the articles on obscure topics are those who go *looking* for them.
Now, I agree that it's still important to have quality standards. The articles still need to be decent articles.
But in most cases (barring obvious vanity-article cases) articles shouldn't be excluded simply because "the topic isn't important enough that we really need an article on it". Wikipedia is much more useful than Britannica precisely because it has articles on almost everything, and Britannica's coverage is, by comparison, extremely spotty.
Sounds to me like your worries had a lot more to do with the belt than the shoes. I said running *shoes* through the machine is a minor inconvenience. I didn't say anything about belts.
(Also, why couldn't you stand there at the conveyor, put the shoes and laptop and stuff in a bin, then take off your belt and put that in, holding up your pants with one hand? When your stuff comes out the other end, grab the belt and put it on first, then pick up the rest of your stuff. Annoying and a little embarrassing, sure, but at least your pants wouldn't fall off. Walking across the room without a belt seems like tempting fate, especially if you're shaped like me and wear loose pants.)
> So, the 9/11 hijackers were all dull & depressed?
The 9/11 hijackers didn't need any particular intelligence to do what they did, because at the time our policy in the event of a plane hijacking was to cooperate with the hijackers and given them what they want until the plane is on the ground. Stupid, but that was our policy for decades.
> a large number of people are forced into using outlook
In every single case, when someone is required to use Outlook, there is somebody at their organization who made the decision to require them to use it. So my point stands.
> When was the last time you used seven-year-old software?
> * Linux kernel: 1991
You're using a version 0.something Linux kernel? Really?
> * Vim: 1992, first port to Unix
I don't know enough about Vim to get specific.
> * Firefox: 2003. It's getting close. If you extend this
> to the Mozilla suite, then you're in the 1990s easily.
Again, you're using Mozilla 1.5?
> * Bash: 1987
I bet you've upgraded that, too. Otherwise it almost certainly wouldn't work with a modern glibc.
I stand by my original assertion. If an open-source project is so inactive that a seven-year-old version is still current and in widespread use, the danger of a closed-source fork seems unimportant.
> I want an accessory that is worn on your torso (as a vest) and delivers
> a paintball-like punch when an in-game bullet strikes your avatar.
Getting punched with a paintball isn't the same thing as getting shot with armor-piercing rounds. Meh. We need better realism than that.
I'm working on a gaming accessory that monitors your in-game situation and, when your character gets shot, actually fires a bullet at the gamer. It's sensitive to the seriousness of the in-game wound, so if your character catches a glancing blow across his thigh from halfway across the game world the real bullet is a low-velocity one and just grazes your thigh, but if your character takes a point-blank shot to the chest you won't be able to keep playing. Patent pending.
Am I the only one who liked the cartooney graphics in Commander Keen?
The problem with IPv6 is that it tried to do too much all at once, most of it completely unnecessary, and some of it arguably not even a good idea. The only part of it we really can't live without is the increase in address size, which could have been handled much more simply with a lot less other change.
> According to metric prefixes accepted in virtually
> every other field, 4096 bytes is 4.1KB
In every other field, it's useful to know how many thousand of something you have.
In computing, however, it is a great deal more useful to know how many 1024-byte kilobytes you have, because space is allocated in power-of-two-sized sectors, so 1024 is either a multiple (two 512-byte sectors) or a factor (a quarter of a 4096-byte sector).
With a 512-byte sector, if I have a bunch of very small (but not zero-size) files and the disk has 128 kilobytes left, I expect to be able to store no more than 256 of my little files in that space. But if some cretinous loser programs the shell to tell me that I have 131 metric "kilobytes", I won't know how much space I really have.
If you want to use metric quantities, use kilobits, megabits, gigabits, and so on (as, indeed, is commonly done when measuring bandwidth). The byte is a power-of-two-based unit, which is what makes it useful for measuring computer storage, because computers do all their arithmetic in binary and for this reason are always going to allocate space (both in volatile memory and on secondary storage) in those terms. It's that way for a reason, and it is going to stay that way.
You'll notice they're not talking about 4000-byte or 40000-bit sectors. That would be dumb.
> A byte can be 10 bits; it's an architecture-specific quantity.
Historically, yes, but not any time recently. Not, for instance, since people started to write software that was portable enough to be compiled for different hardware architectures. If you think codepages and endianness are bad, just *imagine* trying to port your software to an architecture with an exotic byte size! No thanks. Different word sizes and address BUS widths are bad enough.
Yes, at one time long ago, there were other "byte" sizes. But that's reaching pretty far back into the history books. By the time IBM sold their first x86-based "Personal Computer", the entire computing world had fully standardized on the eight-bit byte. DEC, for instance, after dipping their toes in the pool with the PDP-11, finally came fully over to eight-bit bytes with the Vax and thereafter never looked back -- and they were one of the last holdouts.
> People confuse byte and octet all the time, because
> popular hardware architectures use an octet as a byte.
Only the popular ones, eh?
Can you name a hardware architecture, for which new hardware has been manufactured within the last quarter of a century, that uses any byte size *other* than eight bits?
In 1950, your assertion would have been technically accurate, albeit pedantic. But today it's just so much anachronistic nonsense. A byte *is* an octet, period.
Ironically, however, a character is no longer necessarily representable in a single byte.
> But many people don't use their tools every day.
> I'd say that every single one of us have some tools
> that we do use and do like, but we simply don't
> need them every day or even every week.
We're talking about Emacs here. It's a text editor. How on earth could you work on a computer for a whole hour, much less a week, without using a text editor?
Yes, obviously, there *are* people who can go a whole week without using a text editor (except for the extremely lame one built into the textarea handling of their web browser), but such people are quite obviously not part of the target market for Emacs. They play Farmville, can't tell the difference between a banner advert and a dialog box, don't know the difference between a firewall and a virus, and have never heard of Slashdot. They print email so they'll have a copy and then delete it so it won't waste space. If they do for some reason need a text editor, they can use Notepad (or more likely they can go running for help to someone like me). Not only do these people exist, they are in the majority.
But that doesn't mean that Emacs doesn't need to exist. Because, you know, some of us *do* actually use our computers for getting actual work done, not just for watching lame YouTube videos and making stupid PowerPoint presentations.
> If you don't want to compute something right away,
> wrap it up in a lambda and bind it to a symbol
No, I want it to go ahead and *start* calculating, but I don't want to *wait* for it to finish, until I get to the point of actually needing the result, later. This would be especially useful when loading information from a slow source, such as a remote server. Start it, do your other stuff, and *then* check the result.
It goes along with what I said about threading (or I suppose actual forking would get the job done too).
> Selective lazy evaluation is more of an occasional
> syntax convenience for specific problems like streams
Okay, but streams are not exactly an unusual phenomenon. Emacs modules use them for all kinds of things. It would be nice if they were easier to work with.
> I'm honestly curious why it can't just go into
> the same kind of masterpiece-maintenance mode
> as some of Knuth's projects like Tex.
If you are the sort of person who has to ask this question, you cannot possibly understand the answer. I mean, come on, you're happy using a cut-down piece of junk like mg that doesn't even have a lisp interpreter built in. What kind of text editor doesn't even have a high-level language interpreter built in? You'd spend ten or twenty times as long doing everything, for lack of the ability to easily reprogram the editor for the task at hand.
But I will attempt to answer anyway. The following is a list of features that I have looked for in Emacs and found wanting, things that every text editor *ought* to have, and it's disgraceful that Emacs doesn't have them.
I want lazy evaluation. I want to be able to do this:
(setq some-variable (lazy (some-function foo bar)))
And then I want the next thing after that to go ahead and be evaluated. I don't want execution to pause and wait for some-function to complete until some computation actually needs the value of some-variable.
I want better threading support, across the board. Just *one* example is that I want Gnus to be checking for new mail in the background every n seconds while I'm reading my mail, and automatically sort the new messages and insert them into the relevant groups, even if that means inserting them into a group I'm currently reading and updating the message list in real time. Gnus is just one example. I want everything in Emacs to work as if the computer is capable of doing more than one thing at a time, because it's not 1982 any more.
I want some equivalent for CPAN.pm, to make module installation easier. While we're copying features from Perl, I also want a reasonable quoting construct for regular expressions so I don't have to quadruple-backslash everything. Perl-like advanced regex features would also be nice.
I want eshell to have pipe and redirection capabilities. Yes, I know I can use a different shell in shell-mode, but I want the ability to use lisp functions too. I want both capabilities, at the same time, in the same shell.
I want cperl-mode to do a better job with complicated regular expressions and qq(strings) and such. I know it's hard, but I want it anyway.
That's just the stuff I can think of off the top of my head, in a hurry because I need to go get ready for work now.
> Will Emacs then update itself and become self-aware? That
> ought to put the Emacs vs. VI debate to rest once and for all.
I'm not sure it would make any difference, actually. The whole point of vi is to have an editor that doesn't really let you do anything else except edit text. For vi users, this gives it some kind of theoretical aesthetic purity or something.
The only way to really put the Emacs versus vi debate to rest is to create a version of vi that contains a built-in lisp interpreter compatible with the one Emacs is built on. The other side of things is already covered: Emacs has had viper-mode for a long time. But to set the debate fully to rest it needs to go both ways.