TheMiller

This thread made me laugh. I worked on network printing software in Banyan VINES a century or two ago, and my wife always wondered why I hated printing software so much. Everything about the printing software stack, especially in Windows, is terrible.

Washtenaw is certainly an affluent county, but not that rich. I live in another part of the county and used to work in Mauch's part of it; it's by no means mostly millionaires. I think the simplicity of the project's goal -- every household served, no exceptions -- is one of the reasons that it got off the ground.

A minor correction: West was bought by Thomson (no "p"), which later merged with Reuters to become Thomson Reuters.

Well, I still use some UML diagrams fairly often. Not so much for permanent or comprehensive system documentation, but to help me think through specific features or behaviors, and communicate these designs to others. I usually use a smallish subset of UML, because this usage doesn't require deep details.

I did give up on WYSIWYG tools for this, though. PlantUML support in VSCode is pretty good.

I do get it. I've been using it for several months, and I run into problems fairly often. Nothing wrong with the implementation, AFAICT, but it takes a fair amount of thought to assign sites to different containers, and you can easily end up following links that cross container boundaries and then don't work right because of the context change. I've even run into several corporate sites where federated authentication simply won't work in a container, at all.

I think this is a mischaracterization. The relational model which motivated relational DMBSs is based on predicate logic. Mappings to graphs are obvious, but are not the organizing principle. This was one of the strengths of the relational model, encouraging a more flexible view of the data than graph databases had previously offered. In a complex relational schema, you can discover and work with all kinds of implicit graphs that were not originally intended by the schema design.

> UBI is cargo cult finance. It's a broken mental model that will kill the system.

Such dismissiveness is unwarranted. There's a lot of intriguing research on the topic that indicates that it may be a cost-effective replacement for the byzantine social support systems of modern governments, with benefits for both recipients and taxpayers. It only seems like a broken model if you /start/ with an overly simplistic model of the current situation, e.g one that ignores both the existence and desirability of social support systems.

Unfortunately much of the research is frustratingly incomplete. Search e.g. for information on Mincome.

It also seems like a reasonable transition mechanism, from the market economies that have brought us increasing productivity, to a hoped-for post-scarcity future.

I second the recommendation for TheOldReader. It's where I eventually ended up after Google Reader's demise.

At least, it's not the normal case in the U.S. We call that a "holding tank", not a septic tank.

The rural township that I live in is considering the possibility of providing municipal broadband; hence my interest in this report.

From a security point of view, I am skeptical about the ACLU's recommendation in this report to provide open WiFi access points. Due to the danger of MITM attacks, I don't think it's a good idea to promote the use of open APs.

Discover had a service like this more than a decade ago, which I used quite a bit. But they shut it down after a few years.

It's no more of a "technicality" than the fact that some people happened to be born within the somewhat arbitrary borders of a particular nation, through no effort of their own, and thus happen to be considered citizens of that nation.

Actually, in that scenario, the campfire is more likely to be a health threat to asthmatic members of the public (about 7% in the U.S.) than the cigar!

> It was created by people who had no experience in databases and are learning as they go[4]. As they started adding things that are essential for database they realized it's not that simple.

This sounds exactly like what MySQL development looked like to me early in its rise to popularity.

SpiderOak. When I decided I wanted auto-syncing cloud storage, I chose them exactly because of the temp file issue. I ended up also liking their security policies and pricing quite a bit. https://spideroak.com/

I agree with many of the recommendations here, but am surprised to see no mention so far of "the three B's": Gregory Benford, Greg Bear, and Ben Bova. All excellent hard science fiction authors.

"... but those other states' property taxes rise with the value of the houses every year, ..."

In Michigan, it's a bit more complex. The assessor calculates a State Equalized Value (SEV) on which the tax is based, and that cannot rise faster than the rate of inflation, or 5%, whichever is less. I assume lots of states have odd property tax quirks.

I'll second the recommendation for The Culture series, and add "A Fire Upon The Deep" by Vernor Vinge.

I just find it utterly fascinating that these discussions on the merits of (Common) Lisp still draw 100 comments within such a short time. This has been going on for decades, in many different venues. This by itself should clue newcomers in to the notion that the language (family) may be worth examining in some detail. :)

I believe that this convention is borrowed from Common Lisp. I always thought of it more as a way to highlight importance. Three semicolons for block comments outside of top-level constructs, which usually explain the purpose or usage of the following expression (usually a function definition). Two for comments inline with function body code. And one for trailing comments on a line, where space is limited and the comment is least important to understand code structure.

The conventions are even mentioned in the Common Lisp specifications: http://www.lispworks.com/documentation/HyperSpec/Body/02_ddb...

Actually, I can remember at least one commonly used alternative name from my time in a German-speaking country. The term "Pfund" (literally, pound) was frequently used to refer to a half-kilogram. I remember it being particularly used in reference to a loaf of bread, by both bakers and customers. (That was a long time ago, don't know if it's still common.)

They're not mistakes; read the article. "Equality" is not the singular, unambiguous concept that many programmers think it is.

Ahd in Common Lisp, EQ, EQL, EQUAL, and EQUALP. See http://www.nhplace.com/kent/PS/EQUAL.html for an explanation of why.

The cracking community, unlike the bulk of the mainstream programming community, has not lost the art of disassembling executable code. Hiding source code provides negligible additional security.

> Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.

Exceptions do not "explode your call stack", and any function can fail in ways both documented and undocumented. Consistent use of exceptions that derive from a small and well-chosen set of base classes means that callers can choose where and how to respond to categories of errors, instead of being forced to litter all code with error handling conditionals. I have worked on large applications that made the transition to using exceptions, and when combined with strict RAII and other best practices, the effect is absolutely to make code easier to understand and much more robust.

And when you've been writing code for decades, it becomes quite evident that "those other people" can easily be your past selves.

Sorry I didn't follow the link. Given the link's text, "I have been invited", I didn't expect it to lead to background information, but rather just to, well, an invitation. My bad.

The author notably tries to refute arguments against the use of exceptions for control flow, but doesn't present any reasons (at least not in this article) as to why this usage might be a good idea.

There's no compelling reason to introduce odd, non-idiomatic code patterns when they don't confer a significant benefit. Some people here argue that the "intent" of exceptions in a language design is not relevant compared to what can be done with them. In general, I disagree with this. Language designers' intent informs the expectations of readers of code, and your readers' expectations are important. Code is a form of writing for communications, both with the computer and with maintainers; it's not artistic writing, where you might deliberately violate expectations or norms in order to delight or surprise your audience.

That said, using exceptions as a method of transferring control to a non-local, dynamically-bound location is a powerful technique for which few languages offer an explicit alternative. It's also difficult for readers to analyze, so it should be used sparingly. For instance, I can think of reasons that one might use this technique within a container or algorithm library, but I can't think of a good reason for a container library to force this control flow idiom on callers by throwing exceptions to signal common situations.

(As usual, Common Lisp is unusual here. It has a throw/catch feature which is explicitly a flow control mechanism, and not just an error-handling mechanism. The standard documentation is interesting in that the Notes section suggests exactly when one would want to use this mechanism: http://www.lispworks.com/documentation/HyperSpec/Body/s_thro...)

Various exceptions to freedom of speech have been upheld by the Supreme Court; this constitutional right is not absolute. If significant new research results appeared, it would not be surprising if the court to revisited the issue to consider whether another exception is warranted.

I realize this is quite off the main topic, but I thought it was interesting and worth passing on.

If you really think that "four different kinds of equality" in Common Lisp is a wart, then I recommend that you read "The Best of Intentions" (http://www.nhplace.com/kent/PS/EQUAL.html) by Kent Pitman. The article explains why that situation is quite intentional, and why it is very rational, and why it is in fact ill-advised to expect a single meaning for "equal" ... or, in fact, other "obvious" concepts like "copy" ... to be sufficient.

That article was one of the many over the years that helped me refine the way I think about programming and programming languages.