It was intended to make the GSA self-sustaining in budget terms. Under the old system, the costs of running the GSA came out of the Federal budget. The goal back in the '90s was to reduce expenditures in order to cut down the budget deficit. IFF let them push the cost of running GSA off of the Federal budget, by pushing it onto the budgets of the vendors winning GSA contracts.
In terms of lawmaking, the usual way to deal with this problem isn't with front-end analysis, but rather by adding a "sunset provision" (see https://en.wikipedia.org/wiki/Sunset_provision). That's a clause in a bill that requires it to be re-authorized periodically in order to stay in effect. If a law with a sunset provision ends up causing unintended consequences, then lawmakers can let it die just by doing nothing. That's an easier lift than you get in a bill without a sunset provision, which can only be killed if you can convince a majority of lawmakers to actively kill it.
Sunset provisions aren't nearly as widely used as they probably should be.
Being "on the schedule" means you've already been pre-vetted and deemed a legitimate vendor by the GSA. For government agencies, doing business with a contractor on the GSA schedule lets them skip a whole bunch of approvals and paperwork that they'd otherwise have to do if they just pulled in a vendor off the street.
Getting on the schedule can be a long and bureaucratic process, but once you're on it you have a privileged position when it comes to winning government business. So if you want to sell to the Feds, you really want to be on that schedule.
There are static site generators written in Python you could use to publish a blog, like Pelican (https://blog.getpelican.com/) and Lektor (https://www.getlektor.com/). But yeah, if you want software that works like WordPress and generates pages dynamically on the fly, I'm not sure there's any good Python-based alternatives.
> If you thought Perl was a bad language, PHP is way, way worse
In fairness to PHP, it's a lot better today than it used to be. (Though modern PHP would probably strike a Pythonista as too Java-ish.) And WordPress has had tons of engineering resources poured into it for a decade-plus now, whereas Movable Type has been maintained on a relative shoestring due to its fall from popularity.
It would be a sad irony if it did. When Meetup first popped back in the mid-2000s, they very deliberately turned away from the "blitzscaling" model in favor of building a sustainable business. For them to end up as collateral damage of someone else's blitzscaling train wreck fifteen years later would show that God has a dark sense of humor.
The fundamental problem is that there is no singular, unified Microsoft; there is instead a loose confederation of warring tribes that happen to share a headquarters and a ticker symbol. And Windows is the battlefield on which these tribes hash out their disputes.
Tribe A thinks Windows should appeal to people who use and love open source software. Tribe B thinks Windows’ ubiquity makes it a great platform to run ads on. So instead of what most companies would do, which would be to figure out how these goals line up against a broader strategic vision of what Windows should be, at Microsoft they just let both tribes do their thing simultaneously until the leader of one tribe rises up high enough in the org chart to raze the other tribe’s villages and scatter its people to the four winds via a reorg.
This of course results in a deeply schizophrenic product, but that only matters to customers, and Microsoft gave up customers as a false god long ago. Now the only god that matters in Redmond is the God of Battle, and every PM sees his peers as obstacles that need to be cleared away for him to meet his destiny in Valhalla.
Adam is the Alpha and the Omega, the Beginning and the End. Those who invest will inherit all this, and Adam will be their God and they will be his children. But the cowardly, the unbelieving, the shorts -- they will be consigned to the fiery lake of burning sulphur. This is the second death.
with experienced users, e.g. people who are used to vim
... though, is that it basically represents a surrender on the idea that UX is important at all. Given enough time and commitment on the part of the user, any interface can be learned well enough to be adequately useful. You could build an interface out of loaded guns and rotating knives, and a sufficiently committed user could eventually learn how to operate it without killing themselves. The challenge is that most users' time and commitment are not unlimited.
A stronger argument in favor of modal interfaces is that they enable the creation of complex interfaces that wouldn't be possible without modes. This is part of what appeals to so many vim users about vim -- once you've climbed the learning cliff it presents, you can do some things much more efficiently than you could in, say, a WYSIWYG editor. I personally don't agree with that tradeoff, but I recognize that a number of people see it as worthwhile.
I didn't say anything about emacs. emacs has plenty of problems of its own.
> But what is the alternative?
It takes some outside-the-box thinking. Here's an article by Larry Tesler, of Xerox PARC and original-Macintosh-team fame, on how his desire to build a modeless text editor led to the invention of copy-and-paste: http://worrydream.com/refs/Tesler%20-%20A%20Personal%20Histo...
... which is to say, an interface that works differently depending on what "mode" the interface is in.
A classic example of a modal interface is vi/vim, where you have to explicitly switch into "editing" mode in order to actually insert text into the document. And a classic demonstration of why modal interfaces are undesirable can be produced simply by taking someone who's never used vi/vim before, sitting them down in front of it, and telling them to enter a line of text. They will start typing, and immediately become confused when the words they typed don't actually show up anywhere. (Or worse, when they happen to have typed a keystroke that corresponds to a vi command and weird stuff they didn't expect starts happening.)
As you note, modal interfaces are particularly bad in situations where the user needs to operate the system under pressure -- such as (say) on a warship, where the life of the operator may literally depend on them being able to accomplish tasks quickly and accurately. Modal interfaces force the operator to first orient themselves as to what mode the system is currently in before they can do anything, which slows down even experienced operators, and pull away attention that could otherwise be applied elsewhere.
What does all that have to do with touchscreens? Because how a touchscreen operates can be modified with only some programming, they tend to lure developers into building modal interfaces in an effort to cram as many features into them as possible. From a feature-checklist perspective that's great, but from a usability perspective it's a disaster. Anyone who's experienced a modern car infotainment system will understand why -- paging through menu screens to find the one mode with the feature you want while piloting a two-ton hunk of metal at 75mph is a bad combination.
My point wasn't entirely about survivorship bias. People in a surveillance state are going to be especially careful about what they say to people like foreigners and journalists, as those are people who are likely to be under even more close surveillance than are average citizens. So whatever you say to them is very likely going to be something you say in the hearing of the government, even if the person themselves does their best to keep your secret.
> The difference being that China's culture, for the most part, is okay with the surveillance state.
If they weren't, how would you know? Do you honestly think anyone who isn't would be dumb enough to say so out loud, especially to a pollster or a foreigner?
The problem is that these types of regimes tend to preside over a system that's extremely stable, right up to the moment when it really really is not.
Batista's Cuba was very stable and friendly to foreign investment too, for instance. Then along came Castro, and suddenly not only was it not particularly stable, but lots of those foreign companies had all their holdings expropriated by the new government for having collaborated with their oppressor. Oops!
> It doesn't work because users are unwilling to go through and tag all their files.
I tend to agree -- in fact, I was just describing this very idea (that users will go in and mark up their all their content if we just give them the tools to do so) the other day here on HN as "the metadata delusion": https://news.ycombinator.com/item?id=19515848
But it's important to note that tagging as the main usage scenario is envisioned by the linked article, not by those earlier RDBMS-as-filesystem projects. Those older projects assumed that much if not all of the metadata associated with data would be generated and managed by applications sitting on top of the database, using it as their data store. Users could add additional metadata if they wanted to, but they didn't have to for the system to be able to offer benefits.
The RDBMS-as-filesystem argument went more like this. If you want to be able to filter all your documents and only show the completed ones, then yes, allowing you to put a "done" tag on those documents is a crude way of doing that. But if all applications have access to a common data store, more sophisticated options become available, like letting developers build a workflow application that can read your documents and track changes, log approvals/change requests, etc. Then you wouldn't have to tag done documents "done"; you'd just use software to do your work, and your applications would teach the system what it means for a document to be "done".
(Of course, those older projects all fizzled out in the marketplace so we never got the chance to find out how these theories would have played out in practice.)
I'm not sure any of them particularly cared about the terminal. Remember, this was the '90s; all the companies that explored this (Microsoft, Apple, Be) were deeply invested in the GUI as the Future of Computing™.
The theory was that you would never really interact directly with the database; you'd interact with applications, which would just happen to use the database as their data store. So developers could use it to build rich interfaces that were appropriate for the tasks their app was supposed to tackle, and those interfaces would shield the user from the complexity of dealing with the database directly.
The bit about replacing folder hierarchies with tags and search reminds me of some ideas that are actually pretty old now. Back in the '80s and '90s, there was a wave of interest in replacing the traditional filesystem with a relational database, for most of the same reasons as outlined here (we can store more files than we can meaningfully organize, hierarchical organization doesn't really fit lots of use cases, searching is easier than clicking up and down a hierarchy, etc.).
None of these ever really took off, though. Mostly this was because they ran into unsolvable performance problems. Hardware has come a long way since the mid-'90s, though, so it'd be interesting to see if those ideas that were impractical then are practical today.
> How many people are willing to spend thousands on an exercise bike?
In an age when wealth is highly concentrated among a few people, you can make a lot of money selling those few people absurdly overpriced luxury goods.
Are there lots of them? Not really. But they have all the disposable income, so...