Thanks for the informative reply, but it merely provides a workaround. kqueue offered a solution, but Linux could not just adapt it, it had to grow something else, that is, apparently, still not in the production kernels -- that's my grudge...
dnotify is in the production kernels and has been since...before 2.4.x, anyway. It's not as shiny as inotify, but it will do what you want.
kqueue lets me know, when the file grows. For example, tail(1) on FreeBSD uses it (with -f and -F switches). How would you do that with select/poll?
Switch to using FAM (File Activity Monitor) on both systems. It's a daemon implemented on top of kqueue (on *BSD) or dnotify/inotify (on Linux). It talks to instances on other machines to work properly across network filesystems. It also abstracts the underlying API for you. It just gives you a file handle to plug into your monitoring loop, and an API to call when it has input. No need to care if it's using kqueue, dnotify/inotify, or (in the worst-case scenario) a timed loop on the backend.
There's your practical answer. If you'd like to know why you can't directly see when a file handle grows with select/poll, read on.
The thing is that regular files and socket/pipes/character devices are treated in a fundamentally different way on Unix systems. Sockets have nonblocking IO and select/poll. Regular files have much less support - a separate, nasty async API on some systems, and inotify/dnotify on Linux/kqueue on BSD for notifications. (Something on IRIX...they built fam there, after all.) This doesn't make a lot of sense and people like DJB have argued that this doesn't have to be, but...well, that's still how it is.
kqueue is no exception. They've grouped a number of things into the same system call and made it more convenient to safely wait for several types of events at the same time, but you still can't treat them in the same way. On Linux the equivalent of kqueue is accomplished through:
epoll
dnotify/inotify signal handlers
ptrace? I don't remember how you watch processes off-hand.
more signals for async IO
The biggest pain there is handling signals and epoll stuff simultaneously in a correct manner. If you need to, I urge you to check out the documentation for my sigsafe library. It describes some things not to do plus a couple good ways: the self-pipe trick (a popular way if you're using select/poll/epoll) and my own sigsafe_* signal call wrappers.
Most programmers have no little use for spreadsheets, so we don't know how bad they are. We've got a lot of principles that we apply to our own work, but we don't see that the business people are struggling with the same problems without the proper tools.
I made a couple spreadsheets recently, and here's what I found:
Fragile references
They're still referencing virtually everything by [A-Z]\d+. This is beyond GOTO considered harmful - when Dijkstra made that claim, we at least could do "goto blah" instead of "GOTO 2050".
Excel has a couple "solutions", neither of which are good:
You can assign names to cells, but not in a way like "the total of the yearly column of the expenses table". Even if it's in the List Manager, there's still a [A-Z]\d+ cell reference between.
It has relative and absolute references. Relative ones will basically update correctly when you move the source. Both kinds will basically update correctly when you move the target. They've made some effort to make range references expand and contract, too. But it's a heuristic; it's guessing information it doesn't really have.
Massive code duplication
In my spreadsheet today, I ended up with whole columns of formulas like this:
I would have much rather made a function FedIncomeTax(AdjustedGrossIncome) that applied that same bracket logic. Once. And called it the N times necessary. You can define VBA functions, but I didn't see a way to reference cells from them. (Probably because it doesn't have a reliable way to do the dependency/error tracking seamlessly. I can think of how I'd accomplish that in Python...but Python is a very flexible language.)
Unreadable code
There's no way to put longer bits of properly-indented, commented code in there. Certainly related to the above; you're trying to cram way too much stuff into a cell (or group of cells) that's massively repeated, so no one even thinks of doing this.
Poor layout
The result looks poor in a couple ways:
There's no automatic greybarring (alternating light/dark backgrounds for rows). So you can get lost when reading a big table.
An entire worksheet column has the same width. If you have two lists on the same page, inevitably one of them will end up with an awkwardly-sized column.
Poor charting abilities
It didn't have much support for charts with confidence intervals. (Don't tell me there's no use for these in finance! They may write everything out to the nearest cent, but that doesn't mean they don't made wild-ass estimates when talking about the future.) If you want to do something like a box-and-whiskers graph, you have to do elaborate tricks. Even basic error bars have weird defaults; to get a meaningful confidence interval, you have to do custom stuff with ranges. The friendlier check boxes end up with the same-sized error bar for every point, which is worthless.
Overall
Just using Excel for my small needs was frustrating, and it's not because I don't know how to use it. (I can read Help files.) I can easily see how people would screw up badly with them and not notice.
It'd be so much better if there were a more free-form document (no overal grid) you could throw 1-dimensional lists and 2-dimensional tables into. With support for formatting, referencing, and summarizing them well. (There shouldn't be [A-Z]\d+ references at all; the concept shouldn't exist.) Including the PivotTable stuff, of course. (Excel's one good point, though it could be better.)
It also should have support for referencing external data easily - a RDBMS or CSV/
What's with people's fascination with the libraries provided with a language? [...] I always thought that, given that most languages are capable of importing any new libraries you give them, the vocabulary wasn't an issue: if they don't provide you with function XYZ that you can imagine and want, then you just write it yourself, or find someone else who did
Because when you're an open source programmer working on small projects, you want to pull in several different libraries and use them together. If they all have their own string classes, it's all but impossible to use them together. That's unacceptable.
The language design is only have of the picture. As you say, the API is the language's vocabulary. You need a standardized vocabulary to communicate.
It doesn't support variable-length character encodings like UTF-8 or UTF-16.
wchar_t is not a standard size. (It may be two or four bytes, depending on your platform.) So you need to define your own ucs4_t specialization to portably hold wide characters.
There's no decent transcoder in the standard. boost has utf8_codecvt_facet, but currently it's for internal use only. (With a class like this, you could use std::string with above ucs4_t and still do UTF-8 I/O.)
The best workaround I've found is to require Glibmm. It's a huge dependency, but it has a UTF-8 string class and appropriate conversion functions.
But fuck workarounds. I'd rather just code in a language with a standardized string class that doesn't suck. This sort of thing is why my largest C++ project is stagnating while I write code in other languages.
I'd love it even more if my email server was actually a true RDBMS where I could have, besides the traditional IMAP interface, a D (Tutorial D or D4 or something the like) language interface where I could query at will, and save my queries as views that would show up in IMAP as (virtual) folders.
IMAP's closer than you think. If you don't think SQL is relational, you certainly won't think IMAP is, but you can do more than most MUAs support. You can save arbitrary tags on email messages. You can execute surprisingly-sophisticated queries. I recently wrote some crude Jython scripts that use the JavaMail API to do queries like this:
to_me = OrTerm([HeaderTerm(header, "slamb@slamb.org") for header in ["To","Cc","Bcc"]]) to_list = OrTerm([HeaderTerm(header, "") for header in ["List-Post","List-Id","List-Archive"]]) msgs = sourceFolder.search(AndTerm(NotTerm(utils.to_me), utils.to_list))
(sorry about the indentation; ecode apparently doesn't like it.)
You have to read RFC 2060 to know all that IMAP can do.
Yeah, if they don't change the serial number, their secondary name servers will take a long time to expire (could be weeks), but again, this doesn't have anything to do with your claim that if the serial number doesn't change, then the TTL is ignored.
Remember that the article author's actual observation was that old DNS records were being given out. He did not use tools like dig to verify that servers were ignoring the TTL; it was merely a hypothesis. He seems rather ignorant of DNS. He did things like suggesting to people that they reboot to see DNS changes and report back to him, rather than (A) checking himself (B) issuing a command to flush their local cache (C) asking them to hardcode working DNS servers, if the ISP's servers really are broken.
I'd guess that (at least) one of these two things happened:
He decreased the TTL and made the changes...without waiting for records fetched before the TTL decrease to expire. Thus, servers were allowed to keep records until the expiration of his older, longer TTL.
He changed the record but not the serial. His secondary servers did not update. The ISPs which he'd observed to hand out old entries were working correctly, but accessing his secondary servers. Remember, the rest of the world considers them authoritative.
Neither of these support the hypothesis, but they do explain the observed data.
What is the difference between boosts smart pointers and standard C++ auto pointers?
std::auto_ptr<> has this limited and confusing concept of "ownership". Multiple auto_ptrs can point to the same object, but at most one should own it. (Of course, if none do, you have to delete it manually, defeating the point.) Assignment transfers ownership, so it changes the right-hand side of the assignment also.
boost has a couple variants:
The simple boost::scoped_ptr<> always owns what it points to and isn't assignable from another scoped pointer. So it just avoids the ownership thing altogether; it's limited but not at all confusing.
boost::shared_ptr<> is a non-intrusive reference-counting pointer. (The object is destructed when all of the pointers go out of scope or are reassigned to something else.) It's both more powerful and simpler to understand than std::auto_ptr<>. It even supports weak references through boost::weak_ptr<>.
The boost pointers also have variants for arrays; using std::auto_ptr<> with an array would incorrectly use "delete ptr;" instead of "delete [] ptr;" on destruction.
Don't even think about writing C++ code without using boost. In particular, everyone should be using their smart pointers. IIRC, they've been proposed for inclusion in the C++ standard and it's likely to happen.
Kerberos only requires host setup with if the host is a server; that is, to run a kerberized service on it, you need to establish a shared key for the service principal with the Kerberos system (KDC)
My bad; you're right. I was originally thinking of a different situation and confused myself. That situation is single sign-on for all Internet services with a single authentication token. (Like authenticating to slashdot through slamb.org.) Then there wouldn't be a pre-established relation between the service hosts and the KDC, either. Plus, you'd need support for pseudonyms to make it fly with the privacy advocates. I.e., I using my slamb@slamb.org identity to authenticate as anon1932@slamb.org, provided that slamb.org allows it. (Presumably you'd do this with a domain shared by other people, so your identity is not completely obvious anyway.)
But even with the situation I described in the grandparent post, there's still the problem of trusting the computer you're sitting at. Typing a password into an untrusted lab computer is no good. It's an acceptable risk to run a session through there, but to supply authentication information that can be re-used...no thanks.
When are people going to realise that the problem with single sign on isn't a technical one....
The biggest one I see is technical: there's no good single sign-on system designed for the Internet.
Kerberos is the only widely implemented system I'm aware of that implements one key criterium: service providers can't use the credentials passed to them to log in to another service. With web-based single sign-on systems, the password you enter for webmail will also get you in to the billing system. So if the webmail system is compromised (and it's typically held to a much lower standard), so is the billing system. That's no good.[*]
Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in, unless you've instructed them on setting it up. And certainly not on whatever public computer they've run across.
What we need is a single sign-on system with a different model. I think it would require:
a cheap physical token that has public-key cryptography.
a password entered directly into the token that you carry with you. You shouldn't have to trust the machine you're using to not capture your password. That model works for ATMs, but not for net cafes.
no setup for each trust domain on each client machine. Presumably, it would authenticate the domain's keyserver using PKI. Either the existing system where you buy a certificate from Verisign on DNSsec.
wide acceptance - the physical readers should be present on any random machine you stumble across, and so should supporting software.
Certainly #2 and #3 are technical problems. #4 is not. #1 is arguable.
[*] - Some web applications make some effort to avoid this problem. But they're not good enough. The University of Iowa has the HawkID system, which redirects all login requests to the hawkid one, and then back to the application. But you still enter the password into a web form given by the application, and there's no UI for seeing the destination of the form. When you enter it, you don't have a guarantee that the web application doesn't get the password. We need a new system just for authentication that makes potential security problems blindingly obvious.
Google has a problem of returning many results that do not even contain the phrase being looked for. See "miserable failure" for a famous example. 3 of the top 10 results for "to be or not to be" do not even contain the phrase.
Usually, this is because pages that link to it contain that phrase. Maybe not always, though. I searched for my name recently and was unable to account for the top link (lamblion.net). A search for link:www.lamblion.net scott showed no matches. Maybe there used to be a page that had "scott lamb" in a link pointing to lamblion.net...but I don't know why there ever would have been. It's odd.
Wait a minute, are you sure that's right? Won't your formula give you the pixels per diagonal inch?
Yeah, that's what the Pythagorean Theorem bit there does. Then you divide by the diagonal length (which you are given by the manufacturer), yielding the DPI. It should be the same in any dimension, since LCD pixels are square.
Umm, I think you mean cos(arctan(900/1440)) * 17", which yields about 14.4" or a DPI of just about 100. An easier way to think of it is sqrt(1440^2 + 900^2)/17 for DPI. Then divide 1440 and 900 each by DPI to get the dimensions (14.4 x 9).
Ooh, you're right, thanks. I shouldn't do trig in the morning.
Looking at the 17" model, it specifies the screen as having 1440x900. My Dell i8600 with WSXGA has a 15.4" screen (same display aspect ratio too) with 1680x1050. The 15" model has a 15.2" screen with 1280x854, if you want to compare as closely as possible. Is it just me or does Apple not seem to have the best deal here? Apple has been known as the machine to do graphics on but it doesn't lead the class as far as display resolution in a given area?
I think this is a deliberate choice. Apple seems to have the idea of an ideal DPI - see this page, which says "After years of experience, Apple engineers have discovered the ideal resolution to display both sharp text and graphics -- a pixel density of about 100 pixels per inch (ppi)." If my trig is correct, a 1680x1050 screen with a diagonal width of 17" has a horizontal width of arccos(tan(900/1440)) * 17" ~= 13", and a DPI of 1440/13" ~= 110, so this PowerBook is already over their ideal.
In the long run, Apple is clearly wrong - if you have high-resolution images and can scale them any way you like, there's no reason not to display that detail. But for now, scaling probably isn't a good idea. In addition to having to change all the software for it, you'd probably be upscaling slightly, at odd ratios. It would make the images look worse. And having more resolution but not rescaling just means that the icons are smaller and harder to see. I think Apple made the right choice for the short term.
I'm using a 17" PowerBook right now, and for what it's worth, I'm fairly happy with the resolution.
SCons remembers the command line used to compile/build a given file, so it automatically figures out that it should rebuild that file if the command line arguments change. With Make it is very difficult to do that, so "make clean" is used much more often than it should be needed.
There are a couple other reasons "make clean" is used more often than it should:
Generating proper dependencies from source is a pain. SCons does this automatically for all of the built-in builders (notably including C/C++), and it has infrastructure for making your user-supplied builders do the same.
Most makefile setups are recursive. They should not be (see Recursive Make Considered Harmful for a good explanation). It's a pain to make non-recursive make, because the tools aren't set up for it. SCons is.
SCons is written in Python, and the SConstruct files it uses analagously to Makefiles are fundamentally Python scripts
...which is wonderful. The thing about make is that you have to be familiar with so many different syntaxes and APIs to do the simplest thing. There's the shell + make + m4 + autoconf's libraries (workarounds for non-portable shell utilities) + automake's libraries. It's a huge pain, because there's not a single place to look things up. You have to find the appropriate shell utility...then check in the autoconf/automake documentation to see if there are portability wrappers. scons is simpler; you can find most stuff with just their manpage, and possibly Python's documentation when you need to do actual programming in the build system. One (very simple) syntax. Two sources of API documentation.
The autoconf/automake system is nice in that it makes no assumptions about the user's system beyond make - everything is just generated to plain shell scripts and makefiles. But it's such a pain for the developer that it's not worth it. SCons assumes the user has a working Python installation, which makes everything more pleasant. Python provides the same level of functionality with the same interface on every platform.
It's on the server that hosts advertisements, it's a 1x1 invisible placeholder. Apple most likely did not name it that, the ad people (Avenue A, atdmt.com) did.
Actually, I believe Apple named it, but it was probably a typo. Avenue A's site is set up to send out a 1x1 GIF image to any request. Unless you believe the Apple G6 Powerbook is coming out soon also...
Think about it. They announced a lot of other products two weeks ago. They traditionally announce products at that time. Would it make sense for them to start rolling out a Apple G5 Powerbook now?
At first, I was thrown off by the idea of compressing something like pi, as it shouldn't compress. The answer is that they're storing ASCII decimal digits, which require less than 4 bits per number, instead of 8. So you should get at least a 50% compression ratio, which would be 850 million bytes. But it's actually 3.something bits of information per byte, so they're able to fit it on a CD. I would be surprised if bzip could do any better than that.
I had the same thought. To put it in dirt-simple terms, they're only using 10 out of the 256 possible values in every byte, due to the ASCII encoding. This is how bzip2 is able to find any redundancy; pi itself has none.[*]
So the best compression ratio (just compressed size/uncompressed size, right? so lower is better) is ln(10) / ln(256) = 41.5%. On a 700 MiB CD with no filesystem and nothing but pi, this means 700 * 2^20 / ln(256) * ln(10) = 1.77 billion digits (1767655840, with almost room for one more).
You'd do better than bzip2 by just using fixed blocks of N bytes to represent M digits. (Larger choices would get you closer to that best ratio; lower choices would less work to decode each block, which might make seeking more practical and reduce memory requirements.) This would be superior to bzip2 in that it'd get somewhat better compression, use a lot less CPU time, and be seekable. You could encode and decode with a one-line Perl script.
[*] - I suppose you could simply include the algorithm they used to generate the digits...but it'd take a long time to run, negating the whole point of putting pi on a CD.
If you find that the application is making too many SQL queries and is bogging down performance, then ActiveRecord (the database part of Rails) lets you create custom SQL queries.
So what's the problem?
I'm concerned that either of the following would occur:
Even writing the SQL manually, I'd be unable to do it properly because of imposed constraints. Specifically, it's not good enough to just replace each of their queries with manually written ones. You need to restructure some of the surrounding code so each query asks a bigger question. Fewer queries, more goodness.
I'd derail the system. Frameworks like this cut the code down to ridiculously few lines if you do things in their preferred way. But often if you need to go a little outside that, you end up writing as much code as you would have without the framework, if not more. You just end up needing to understand an additional layer of complexity that doesn't actually help you.
The ACL example put such a bad taste in my mouth that I probably won't ever take the effort to see if these are true.
It is impressive to produce that working (although spartan) website with a single line of code. But...
Last time Ruby on Rails came up, someone mentioned this example showing off their object-relational mapping. I observed then that it makes way too many queries because the SQL it produces isn't very good. (And too many queries means a lot of slowness, especially when your database server and your webserver aren't on the same machine.)
It's not as obvious here because all of the queries are behind the scenes, but I suspect the same sort of crappy SQL is driving this example.
I got excited for a second when I saw the "nullable types". I was hoping for a second this was a more radical feature that I saw somewhere (in Cyclone, maybe):
You can say if a reference is "nullable" or not. Nullable references can always be assigned any value; non-nullable references can always be assigned from non-nullable references. When you try to assign a non-nullable reference from a nullable one, there's a runtime check inserted.
In other words, it'd be a safety feature. In a lot of cases, it doesn't make sense to pass null to a method. With this feature, it'd be possible to see from the method signature if that's true. It'd save writing a bunch of assertions for those of us who already are picky about this stuff, and be a hint to others that they should be, too. And those assertions are quite useful - they make the program fail sooner, closer to the code that caused the error.
Instead, this is a feature that just lets you assign null to primitive types. By a completely different mechanism than you use for classes. Boring to me - I like languages where there are no special primitive types. Enhancements to them - especially additional differences to remember - won't get me excited.
Direcway satellite. I'm in MD hitting a geosync satellite for my Internet. Average ping time is ~750ms to most sites. Nowhere near "3.75-4 seconds"
750ms is actually worse than I would have expected.
The contributing factors that I see are:
477 ms: four trips between the earth and the satellite. (Ping from ground to satellite to ground, pong from ground to satellite to ground.) Geosynchronous orbit is 35,786 km above the surface. So in the optimistic case (satellite directly above both sides of the connection), that adds 4*35,787 km/s/3.00e8 m/s * 1e3 m/km =.477 sec.
less than 8.5 ms: additional time to a satellite not directly overhead. You add no more than the Earth's radius to each trip (and less, I think. It's not significant enough to bother doing the geometry to nail it down more.) That's an additional 4*6,378 km / 3.00e8 m/s * 1e3 m/km =.0850 sec.
~40 ms: processing. My pings, which travel an insigificant distance, tend to be in this range.
over 200 ms: ???
And yes if you're interested, World of Warcraft runs just fine...
But not Counterstrike, I'm sure. The nearly half-second delay geosync satellites must add makes them completely useless for some things. And makes people want to reduce the number of trips. It sounds like this Air Force project is designed to ensure each packet goes source->satellite->destination rather than source->satellite->ground router->satellite->destination.
But it's not that RPM *lets* you do package-centric management - rather the issue is that.deb *requires* it.
I disagree. The issue is that Debian requires you to do it a certain way. They could still do this if they used RPM. They have many other packaging rules that aren't enforced by the format, so I don't see any problem with one more.
They could additionally say "don't install non-Debian packages on a Debian system" and come up with a simple way to stop people from accidentally breaking this rule. (Perhaps requiring a dependency on a "debian" virtual package, with a "--non-debian" option to override.) Thus, they could share the toolset of the RPM world without compromising their project's goals.
What else would you have them do? Would you have them remove all mention of opinions? That'd be completely inappropriate - your knowledge of the topic would be lacking without knowing this controversy exists and the arguments of both sides.
As you say, they acknowledge the nature of the debate and present both sides. Furthermore, they present them well, with a great deal of supporting evidence. They don't simply state that there are multiple opinions without giving you information and references to judge for yourself their validity. ("We report, you decide," right?)
Yes, there is a lot more evidence there to support the claim that FOX News is has a conservative bias. Frankly, I believe this is because contrary evidence does not exist. If you know better,
fix it! I just skimmed the most recent of the history section for this article. While I did see conservative statements removed, they were horribly-written, unsubstantiated opinions, rather than descriptions of and references to supporting facts like the liberal side had - such as the information about the bovine growth hormone court case.
.deb is package-oriented. A.deb lists package dependencies that it requires: the name of the package and the version information. [...]
An example: if package my-app depends on x-window-manager, my-app will only install if some package claims to be "x-window-manager". This could be an actual "x-window-manager" or a virtual package provided by, say "enlightenment" and/or "metacity".
RPM can do this, too. IIRC, recent Fedora systems have dependencies on smtp-daemon, which can be satisfied by either sendmail or postfix. And it provides system-config-mail which supplies a sendmail interface which dispatches to the one you have configured.
.rpm is file-oriented: a package lists its dependencies as files it requires.
.rpm can be file-oriented. It's the choice of the one making the package.
I'm not aware of anything.deb can do that.rpm can't, despite Debian fans raving about their superior package format. All of these things are more about the way the packages are made than the actual format.
Slashdot Mirror
dnotify is in the production kernels and has been since...before 2.4.x, anyway. It's not as shiny as inotify, but it will do what you want.
Switch to using FAM (File Activity Monitor) on both systems. It's a daemon implemented on top of kqueue (on *BSD) or dnotify/inotify (on Linux). It talks to instances on other machines to work properly across network filesystems. It also abstracts the underlying API for you. It just gives you a file handle to plug into your monitoring loop, and an API to call when it has input. No need to care if it's using kqueue, dnotify/inotify, or (in the worst-case scenario) a timed loop on the backend.
There's your practical answer. If you'd like to know why you can't directly see when a file handle grows with select/poll, read on.
The thing is that regular files and socket/pipes/character devices are treated in a fundamentally different way on Unix systems. Sockets have nonblocking IO and select/poll. Regular files have much less support - a separate, nasty async API on some systems, and inotify/dnotify on Linux/kqueue on BSD for notifications. (Something on IRIX...they built fam there, after all.) This doesn't make a lot of sense and people like DJB have argued that this doesn't have to be, but...well, that's still how it is.
kqueue is no exception. They've grouped a number of things into the same system call and made it more convenient to safely wait for several types of events at the same time, but you still can't treat them in the same way. On Linux the equivalent of kqueue is accomplished through:
The biggest pain there is handling signals and epoll stuff simultaneously in a correct manner. If you need to, I urge you to check out the documentation for my sigsafe library. It describes some things not to do plus a couple good ways: the self-pipe trick (a popular way if you're using select/poll/epoll) and my own sigsafe_* signal call wrappers.
I made a couple spreadsheets recently, and here's what I found:
Fragile references
They're still referencing virtually everything by [A-Z]\d+. This is beyond GOTO considered harmful - when Dijkstra made that claim, we at least could do "goto blah" instead of "GOTO 2050".
Excel has a couple "solutions", neither of which are good:
Massive code duplication
In my spreadsheet today, I ended up with whole columns of formulas like this:
I would have much rather made a function FedIncomeTax(AdjustedGrossIncome) that applied that same bracket logic. Once. And called it the N times necessary. You can define VBA functions, but I didn't see a way to reference cells from them. (Probably because it doesn't have a reliable way to do the dependency/error tracking seamlessly. I can think of how I'd accomplish that in Python...but Python is a very flexible language.)
Unreadable code
There's no way to put longer bits of properly-indented, commented code in there. Certainly related to the above; you're trying to cram way too much stuff into a cell (or group of cells) that's massively repeated, so no one even thinks of doing this.
Poor layout
The result looks poor in a couple ways:
Poor charting abilities
It didn't have much support for charts with confidence intervals. (Don't tell me there's no use for these in finance! They may write everything out to the nearest cent, but that doesn't mean they don't made wild-ass estimates when talking about the future.) If you want to do something like a box-and-whiskers graph, you have to do elaborate tricks. Even basic error bars have weird defaults; to get a meaningful confidence interval, you have to do custom stuff with ranges. The friendlier check boxes end up with the same-sized error bar for every point, which is worthless.
Overall
Just using Excel for my small needs was frustrating, and it's not because I don't know how to use it. (I can read Help files.) I can easily see how people would screw up badly with them and not notice.
It'd be so much better if there were a more free-form document (no overal grid) you could throw 1-dimensional lists and 2-dimensional tables into. With support for formatting, referencing, and summarizing them well. (There shouldn't be [A-Z]\d+ references at all; the concept shouldn't exist.) Including the PivotTable stuff, of course. (Excel's one good point, though it could be better.)
It also should have support for referencing external data easily - a RDBMS or CSV/
Because when you're an open source programmer working on small projects, you want to pull in several different libraries and use them together. If they all have their own string classes, it's all but impossible to use them together. That's unacceptable.
The language design is only have of the picture. As you say, the API is the language's vocabulary. You need a standardized vocabulary to communicate.
It doesn't support Unicode well. Specifically,
The best workaround I've found is to require Glibmm. It's a huge dependency, but it has a UTF-8 string class and appropriate conversion functions.
But fuck workarounds. I'd rather just code in a language with a standardized string class that doesn't suck. This sort of thing is why my largest C++ project is stagnating while I write code in other languages.
IMAP's closer than you think. If you don't think SQL is relational, you certainly won't think IMAP is, but you can do more than most MUAs support. You can save arbitrary tags on email messages. You can execute surprisingly-sophisticated queries. I recently wrote some crude Jython scripts that use the JavaMail API to do queries like this:
(sorry about the indentation; ecode apparently doesn't like it.)
You have to read RFC 2060 to know all that IMAP can do.
Remember that the article author's actual observation was that old DNS records were being given out. He did not use tools like dig to verify that servers were ignoring the TTL; it was merely a hypothesis. He seems rather ignorant of DNS. He did things like suggesting to people that they reboot to see DNS changes and report back to him, rather than (A) checking himself (B) issuing a command to flush their local cache (C) asking them to hardcode working DNS servers, if the ISP's servers really are broken.
I'd guess that (at least) one of these two things happened:
Neither of these support the hypothesis, but they do explain the observed data.
std::auto_ptr<> has this limited and confusing concept of "ownership". Multiple auto_ptrs can point to the same object, but at most one should own it. (Of course, if none do, you have to delete it manually, defeating the point.) Assignment transfers ownership, so it changes the right-hand side of the assignment also.
boost has a couple variants:
The boost pointers also have variants for arrays; using std::auto_ptr<> with an array would incorrectly use "delete ptr;" instead of "delete [] ptr;" on destruction.
boost also has a nice unit testing library. I use it for all my C++ code.
My bad; you're right. I was originally thinking of a different situation and confused myself. That situation is single sign-on for all Internet services with a single authentication token. (Like authenticating to slashdot through slamb.org.) Then there wouldn't be a pre-established relation between the service hosts and the KDC, either. Plus, you'd need support for pseudonyms to make it fly with the privacy advocates. I.e., I using my slamb@slamb.org identity to authenticate as anon1932@slamb.org, provided that slamb.org allows it. (Presumably you'd do this with a domain shared by other people, so your identity is not completely obvious anyway.)
But even with the situation I described in the grandparent post, there's still the problem of trusting the computer you're sitting at. Typing a password into an untrusted lab computer is no good. It's an acceptable risk to run a session through there, but to supply authentication information that can be re-used...no thanks.
The biggest one I see is technical: there's no good single sign-on system designed for the Internet.
Kerberos is the only widely implemented system I'm aware of that implements one key criterium: service providers can't use the credentials passed to them to log in to another service. With web-based single sign-on systems, the password you enter for webmail will also get you in to the billing system. So if the webmail system is compromised (and it's typically held to a much lower standard), so is the billing system. That's no good.[*]
Kerberos isn't designed for the Internet. You need to set it up explicitly for each trust domain on each client computer. So users can't just pull out their personal laptops and use them to log in, unless you've instructed them on setting it up. And certainly not on whatever public computer they've run across.
What we need is a single sign-on system with a different model. I think it would require:
Certainly #2 and #3 are technical problems. #4 is not. #1 is arguable.
[*] - Some web applications make some effort to avoid this problem. But they're not good enough. The University of Iowa has the HawkID system, which redirects all login requests to the hawkid one, and then back to the application. But you still enter the password into a web form given by the application, and there's no UI for seeing the destination of the form. When you enter it, you don't have a guarantee that the web application doesn't get the password. We need a new system just for authentication that makes potential security problems blindingly obvious.
Usually, this is because pages that link to it contain that phrase. Maybe not always, though. I searched for my name recently and was unable to account for the top link (lamblion.net). A search for link:www.lamblion.net scott showed no matches. Maybe there used to be a page that had "scott lamb" in a link pointing to lamblion.net...but I don't know why there ever would have been. It's odd.
Yeah, that's what the Pythagorean Theorem bit there does. Then you divide by the diagonal length (which you are given by the manufacturer), yielding the DPI. It should be the same in any dimension, since LCD pixels are square.
Ooh, you're right, thanks. I shouldn't do trig in the morning.
I think this is a deliberate choice. Apple seems to have the idea of an ideal DPI - see this page, which says "After years of experience, Apple engineers have discovered the ideal resolution to display both sharp text and graphics -- a pixel density of about 100 pixels per inch (ppi)." If my trig is correct, a 1680x1050 screen with a diagonal width of 17" has a horizontal width of arccos(tan(900/1440)) * 17" ~= 13", and a DPI of 1440/13" ~= 110, so this PowerBook is already over their ideal.
In the long run, Apple is clearly wrong - if you have high-resolution images and can scale them any way you like, there's no reason not to display that detail. But for now, scaling probably isn't a good idea. In addition to having to change all the software for it, you'd probably be upscaling slightly, at odd ratios. It would make the images look worse. And having more resolution but not rescaling just means that the icons are smaller and harder to see. I think Apple made the right choice for the short term.
I'm using a 17" PowerBook right now, and for what it's worth, I'm fairly happy with the resolution.
SCons remembers the command line used to compile/build a given file, so it automatically figures out that it should rebuild that file if the command line arguments change. With Make it is very difficult to do that, so "make clean" is used much more often than it should be needed.
There are a couple other reasons "make clean" is used more often than it should:
SCons is written in Python, and the SConstruct files it uses analagously to Makefiles are fundamentally Python scripts
...which is wonderful. The thing about make is that you have to be familiar with so many different syntaxes and APIs to do the simplest thing. There's the shell + make + m4 + autoconf's libraries (workarounds for non-portable shell utilities) + automake's libraries. It's a huge pain, because there's not a single place to look things up. You have to find the appropriate shell utility...then check in the autoconf/automake documentation to see if there are portability wrappers. scons is simpler; you can find most stuff with just their manpage, and possibly Python's documentation when you need to do actual programming in the build system. One (very simple) syntax. Two sources of API documentation.
The autoconf/automake system is nice in that it makes no assumptions about the user's system beyond make - everything is just generated to plain shell scripts and makefiles. But it's such a pain for the developer that it's not worth it. SCons assumes the user has a working Python installation, which makes everything more pleasant. Python provides the same level of functionality with the same interface on every platform.
Actually, I believe Apple named it, but it was probably a typo. Avenue A's site is set up to send out a 1x1 GIF image to any request. Unless you believe the Apple G6 Powerbook is coming out soon also...
Think about it. They announced a lot of other products two weeks ago. They traditionally announce products at that time. Would it make sense for them to start rolling out a Apple G5 Powerbook now?
I had the same thought. To put it in dirt-simple terms, they're only using 10 out of the 256 possible values in every byte, due to the ASCII encoding. This is how bzip2 is able to find any redundancy; pi itself has none.[*]
So the best compression ratio (just compressed size/uncompressed size, right? so lower is better) is ln(10) / ln(256) = 41.5%. On a 700 MiB CD with no filesystem and nothing but pi, this means 700 * 2^20 / ln(256) * ln(10) = 1.77 billion digits (1767655840, with almost room for one more).
You'd do better than bzip2 by just using fixed blocks of N bytes to represent M digits. (Larger choices would get you closer to that best ratio; lower choices would less work to decode each block, which might make seeking more practical and reduce memory requirements.) This would be superior to bzip2 in that it'd get somewhat better compression, use a lot less CPU time, and be seekable. You could encode and decode with a one-line Perl script.
[*] - I suppose you could simply include the algorithm they used to generate the digits...but it'd take a long time to run, negating the whole point of putting pi on a CD.
I'm concerned that either of the following would occur:
The ACL example put such a bad taste in my mouth that I probably won't ever take the effort to see if these are true.
Last time Ruby on Rails came up, someone mentioned this example showing off their object-relational mapping. I observed then that it makes way too many queries because the SQL it produces isn't very good. (And too many queries means a lot of slowness, especially when your database server and your webserver aren't on the same machine.)
It's not as obvious here because all of the queries are behind the scenes, but I suspect the same sort of crappy SQL is driving this example.
You can say if a reference is "nullable" or not. Nullable references can always be assigned any value; non-nullable references can always be assigned from non-nullable references. When you try to assign a non-nullable reference from a nullable one, there's a runtime check inserted.
In other words, it'd be a safety feature. In a lot of cases, it doesn't make sense to pass null to a method. With this feature, it'd be possible to see from the method signature if that's true. It'd save writing a bunch of assertions for those of us who already are picky about this stuff, and be a hint to others that they should be, too. And those assertions are quite useful - they make the program fail sooner, closer to the code that caused the error.
Instead, this is a feature that just lets you assign null to primitive types. By a completely different mechanism than you use for classes. Boring to me - I like languages where there are no special primitive types. Enhancements to them - especially additional differences to remember - won't get me excited.
750ms is actually worse than I would have expected.
The contributing factors that I see are:
And yes if you're interested, World of Warcraft runs just fine...
But not Counterstrike, I'm sure. The nearly half-second delay geosync satellites must add makes them completely useless for some things. And makes people want to reduce the number of trips. It sounds like this Air Force project is designed to ensure each packet goes source->satellite->destination rather than source->satellite->ground router->satellite->destination.
I disagree. The issue is that Debian requires you to do it a certain way. They could still do this if they used RPM. They have many other packaging rules that aren't enforced by the format, so I don't see any problem with one more.
They could additionally say "don't install non-Debian packages on a Debian system" and come up with a simple way to stop people from accidentally breaking this rule. (Perhaps requiring a dependency on a "debian" virtual package, with a "--non-debian" option to override.) Thus, they could share the toolset of the RPM world without compromising their project's goals.
As you say, they acknowledge the nature of the debate and present both sides. Furthermore, they present them well, with a great deal of supporting evidence. They don't simply state that there are multiple opinions without giving you information and references to judge for yourself their validity. ("We report, you decide," right?)
Yes, there is a lot more evidence there to support the claim that FOX News is has a conservative bias. Frankly, I believe this is because contrary evidence does not exist. If you know better, fix it! I just skimmed the most recent of the history section for this article. While I did see conservative statements removed, they were horribly-written, unsubstantiated opinions, rather than descriptions of and references to supporting facts like the liberal side had - such as the information about the bovine growth hormone court case.
RPM can do this, too. IIRC, recent Fedora systems have dependencies on smtp-daemon, which can be satisfied by either sendmail or postfix. And it provides system-config-mail which supplies a sendmail interface which dispatches to the one you have configured.
.rpm can be file-oriented. It's the choice of the one making the package.
I'm not aware of anything .deb can do that .rpm can't, despite Debian fans raving about their superior package format. All of these things are more about the way the packages are made than the actual format.