I feel the premise of "the OS as a Language" is missing a very critical point: our common definition of what "a computer is" has changed drastically in the intervening years.
Take a close look at those early computers. It is easy to ask "why do we even need an OS" when we don't have extra things like USB, hard drives, or RAM (it's all just storage anyway). What was once called "a computer" is now known as "a processor."
Even within the CPU itself we find layers of abstraction: caches, interpreters, even out-of-order execution! Just because you write assembler today, doesn't mean the processor is going to do exactly what you specified.
Some of these abstractions should be questioned and challenged, such as the CISC instruction set I alluded to above. But we should remember _why_ these abstractions are there in the first place, instead of blindly questioning (or accepting) how things work.
We're trying. Our not-too-far-off alternative is to require whoever owns the physical cable within the city to sell services to other providers (usually for a regulated fee).
Basically what we did for long-distance phone service. The recent FCC ruling stopped short of doing just that, but it isn't a stretch of the imagination for the FCC to apply full teleco rules to cable providers in the US.
Of course, every ISP is going to lobby extremely hard against that. But one can only hope...
> I don't get the general negativity around Windows.
For me, it's that the system is completely closed and opaque, and there routinely isn't much I can do about it.
Not saying the other guys are perfect--far from it--but at least I can take a crack at changing things. Windows is the most closed-source OS I run (more so than OSX). When it doesn't do The Right Thing, I can get very negative.
And to your point, I feel I've learned much more from OSes that expose the internals and let me mess with them, than those that don't.
Point of this article is not the point of this article. The clever bit was:
> ...the IPv4 address will convert into a number...
Many fancy, post-modern app developers might insist, "You won't do math with an address; it's not a number." But some things are numbers, with a scheme and pattern you can exploit.
Depends on the resolution and scan area you're talking about. I think the .5km can go off every 15min. But the 2km can go out every 5.
But that's nothing. IIRC, the Mesoscale (a 1000km x 1000km box somewhere in the hemisphere) can go out every 30s. On top of that, I believe you can snap a Meso without interrupting normal operations.
Here in the US, the idea of getting a snapshot of a Tropical Wave out every 30s during, say, hurricane season is very, very exciting.
Interesting. I take a similar approach, but then I add testing (which usually coincides with fixing some bug).
Find an entry point to the system, then make it compile, then make the test run, then just keep on nudging the code until I'm satisfied I've covered what I'm interested in.
If I stay true to my mantra "only add test code when it is absolutely necessary" (is this argument needed? pass null and find out), I find an accurate (albeit not pretty) description the flow through that procedure.
Then you commit your test and save your discovery for posterity.
Setting up the projection is the most difficult part. Also one a lot of people have worked on, PROJ4 [http://trac.osgeo.org/proj/]
Were I to grab a projector and a hemisphere screen, I'd probably just reproject to azimuthal (or maybe even conformal), point the projector at the screen, and hope people don't pay too much attention to the very edge.
> ...my thesis was that the Great Firewall is economically beneficial for China.
Not quite.
While protectionism can help bootstrap a domestic industry, shutting out competition doesn't always build an industry that can compete internationally. Worse yet, your industry might get involved in the political process and entrench its way of business.
Look at the Brazilian auto industry. About 50 years ago, Brazil passed import controls to boost the domestic auto industry. Today Brazil has one of the top 10 auto makers (can't remember which), and they export to...Argentina. Meanwhile Toyota--keeping in mind how big Toyota was 50 years ago--exports everywhere.
Building up the domestic market then moving to exports isn't a proven way to build up an industry. Being export-driven first, then focusing domestically is.
(I'm off topic from sanctions here, but there is a reason tariffs don't work)
> I don't understand the whole "If you behave logically as a business we hate you" sentiment.
FWIG, Cuban's attitude sounds like "what is good for the business isn't always good for the investor". In a less twitter-friendly format, filing offshore creates a tax-shortfall that will be borne by your stakeholders. While this cost might not be felt by Mr. Cuban, in this case he would be acting logically (in a sense).
> It is the job of a business to make money, the most money possible, at all costs.
First time I've heard that one. Here I thought the purpose of a business was to create value for its stakeholders. Mind you, value can be products for your consumers, jobs for your employees, or capital for your owners. Usually this means money, but not always.
I work in government contracts, so your example of complying with the tax code was oddly relevant.
There are plenty of places that follow along your example: I can build a general solution that will withstand a wide range of changes. This doesn't change the fact that a change could come along that I didn't anticipate. What I would call "debt" is more the result of changes in requirements than choices the team made.
You can still frame dealing with change as classic "technical debt", except the full cost/benefit of each design can't be well known. Instead it looks more like "technical investment"; you try make a design that will pay off, but you don't have a guarantee that it will.
I find myself hedging a lot of my designs, and rarely am I able to justify spending a lot of time up front on any architecture.
Part of my point is that you don't feel over-engineering nearly as much. If it is under-engineered, it probably doesn't work, and at least has a list of pain points that are fairly obvious.
Over-engineered components will work (sometimes flawlessly), so you don't realize you've spent too much time and money on something until long after you built it.
The issue I deal with isn't in choosing a design that scales better, it is uncertainty in how things will scale. Say I need to handle group permissions depending on the context. I could hard-code the permissions changes for the one group that needs it now, or I could abstract and generalize context-switching behavior into its own component, ensuring changes to future groups will be easy and low-cost.
But, what if I never get a second group that needs this? While hard-coding values was an ugly shortcut, I may never have a need to revisit the code. If I had gone with a generalized solution, I'd still have to contend with maintaining all that code.
Sounds like you have a good idea of what I'm on about. Still leaves me searching for a way to deal with my system.
Take your tax-software example. You need to start work before the law is written, but there could be changes in the law that require a rework of business logic. What do you work on? How do you prioritize? And how do you deal with that subsystem that no longer has a reason to exist?
In my domain, technical debt is not really a choice I make. It is something that happens as the system ages. I wish I could get someone to speak to that.
In my line of work, either I'm building a new component, or I'm dealing with requirements change. So dealing with the shifting sands of what the system should do is a major concern.
Requirements come and go for me. And losing requirements can be just as disruptive as getting them. Worried about how component X will handle users? Well, we don't ship component X anymore, so any refactoring work you've done is wasted.
I might be the odd one out with requirements changing all the time, but I don't get the choice between good design and fast design. I have to creep forward in my architecture, like I'm fumbling around in the dark, because what my system should do today may not hold until tomorrow.
I'm not really a fan of the story-point example. The article begins with:
> it’s something that you get when you delay design decisions for later
But then presents us with a problem where we can "spend" 21 story points now, knowing we won't have to do much refactoring later. How do we know this? I thought the whole point was we couldn't see enough of the picture to make a stable design.
Instead of talking about how patches, hacks, and workarounds impact code, I'd like to see discussion on how you move forward when you know the requirements are going to change, but don't know how.
Never dismiss the dangers of over-engineering. While not as terrifying as under-engineering, how useful is a feature that exists only for the purity of design?
So, I could get on my soapbox of "your students are adults, let them make their own decisions on note taking" or go on about how useful I found a calendar for remembering class schedules, but:
> We still haven’t made it easy to type notation-laden sentences, so the potential benefits were low.
Really? I found it fairly easy to type out full equations in LaTeX using LyX. Maybe the laptop isn't the problem, but that you only introduce your students to the most basic of word processors.
The age distribution in China is not that far off from the US[1]. This gives China a similar entitlement expenditure per person as in the US, but without the same level or distribution of income.
US population growth has been outpacing China and Europe for the last decade [2]. If trends stay about the same (no plagues, massive wars, or other major changes in population), the population growth happening today will translate to growth in the work force 20 to 30 years from now. Note: population growth includes immigration, which is something the US experiences more of than China or Europe.
In a nutshell, we expect the Chinese demographics to shift older faster than the US. This raises questions on how China will fund services, entitlements, etc 30 years from now (which is what I imagine Joffe was getting at).
Take a close look at those early computers. It is easy to ask "why do we even need an OS" when we don't have extra things like USB, hard drives, or RAM (it's all just storage anyway). What was once called "a computer" is now known as "a processor."
Even within the CPU itself we find layers of abstraction: caches, interpreters, even out-of-order execution! Just because you write assembler today, doesn't mean the processor is going to do exactly what you specified.
Some of these abstractions should be questioned and challenged, such as the CISC instruction set I alluded to above. But we should remember _why_ these abstractions are there in the first place, instead of blindly questioning (or accepting) how things work.