cbdfghh

>EE is open source

It is _not_. You cannot distribute it. That makes it not open source.

So what's the advantage of using Android over straight Linux?

Just curious, is a Go string a C string inside (rune array + nil) or a proper class array?

In other words, in

a:="b"+"c"

IOW, does it implement the Slemiel's painting algorithm or not?

>Hasn't happened. Won't happen.

I don't know about five years. But in 25 I don't know if you'll be able to differentiate your computer from your (old, dumb) TV, except you'll have fewer rights

Not everywhere. CA, for example, doesn't permit them.

But companies also have non-compete (or other exclusionary) clauses which are legal outside of anti-trust laws.

>employees weren't allowed to quit

In the US you can quit and look for another job, the same way how MS can exit the OS market.

The same way MS doesn't leave the OS market (too lucrative), most people don't walk off on their jobs.

The issue is that US workers now compete with the whole world.

Until the 70s, the US really had no competition. To compete, you need a stable (legal) system - No one would invest money in a country where it's not far-fetched that someone will overthrow the government, nationalizes your company and throws you in jail.

Oh, and because of geo-politics, one couldn't invest in USSR friendly countries (both from the US side and the other side)

So no one would invest in the USSR, Africa, the Middle East, China or India, Europe and Japan were in shambles. So who built up industry? The US.

After the 60s, different countries started stabilizing. First Japan, then China, now most of the world is actually quite stable, so now the average US worker has to compete against all of India, China, Bangladesh, etc.

You have more supply and the same demand (the world).

And the problem is nothing can really be done about it.

>It's like employers don't even attempt to think about anything from the employee's perspective -- even after they've struggled to fill their own positions. "Cheap business owners" couldn't be a more accurate byline.

Or maybe the job their trying to fill isn't worth that much to them (the employers, that is)?

As an example, let's take a speech-writer for a presidential candidate.

Company X (let's say it has 100 billion in the bank) wants a website, so it looks for an SEO firm, but it's cheap and not interested in investing in the website.

X doesn't get skilled SEO consultants.

X now has three choices - get minimum quality workers, drop the website project or pay more for better workers.

Obviously, workers would prefer if X choses 3, but there are times when it just doesn't make sense to do so (or the company doesn't _think_ it needs to do so, and goes out of business):

What if a company has a small audience comprised of people who don't find things online.

Let's say the company runs a program only senators would use. That's a hundred person market which practically requires personal connection to their staff to make a deal.

Hiring someone for $250,000 website is just not worth it.

Practically, in a capitalist environment, workers are "contractors" selling themselves.

The same way I would not pay for a big-iron computer when all I need is a laptop, companies don't want to pay $200,000 when they can find someone for less.

Would it be possible to take ebay to a small claims court?

In a library, breaking releases should be far fewer than "regular" feature releases. My point is that if you break code more than a few times in the history of your library, you'll get a revolution. For example, see Python 2->3, which was a relatively "small" fix (which just happened to affect pretty much half of existing string processing code), and PHP, where they seem to introduce and then turn around and remove those features every couple years (mysql, no, mysqli, no, PDO? Are we there yet?)

The point of Semantic Versioning is to tell you something.

So let's say you have Compiler 5.3.2

It means that the important thing is compiler #5. Upgrading from 4 to 5 is a _Big Deal_. You may have to rewrite all your code.

Within 5, you have a version 3. 3 has features A,B,C which 2 doesn't have. Most additions go there. So it should be safe to upgrade.

Within that, you have bugfix #2. That _should_ always be upgraded, unless you rely on undocumented features.

So it's easy for me to tell if I should upgrade.

So upgrading from Apache 1 to Apache 2 may brake config scripts and .htaccess files. Don't upgrade on production build.

Upgrading Apache 1.1 to 1.2, See README, Should be fine, do a small test on your testing machine.

Upgrading Apache 1.1.2 to 1.1.3. Probably a security fix. Do so. Immediately.

---------

The OP's numbering system doesn't tell me anything. should I upgrade 5.4.3.2 to 5.5.0.0? Will it be safe? Probably not. You may have to schedule a full testing load just to be sure.

What about from 5.4.3.2 to 6.4.0.0? Same thing. You have to do a full testing.

And if you _really_ break old code, do everyone a favor and rename your project (So, no, please don't call Go C++ V.13 or something)

> If you're using a proper type-safe compiled language then most "subtle" breaking changes can't possibly be missed because your code won't compile anymore (assuming you used that API to begin with). You don't need a major version number to call attention to the fact that one parameter of one method changed from a boolean flag to a set of options, anyone who's using that method will find that out pretty quickly.

1. What if it's a dll, .so? You upgrade and find out that your program is broken.

2. Sometimes the API stays the same but the code behind the API changes a result (for example, secure_hash goes from MD5 to bcrypt)?

3. What about non-type safe languages (like HTML or JS, so things like Firefox or Chrome)?

The point is that you should avoid breaking other people's code if you can. What happened if that removal of one function in that one module costs me a full years of work?

Sometimes you can't help yourself. PHP had register_globals. Some people were able to use it safely (initialize all variables before use), but PHP rightfully realized the security implications and disabled it. However, it broke code, and a lot of it.

These are things you should think about and heavily before breaking code. It may be one line for you, but for all the millions of people who use your library it could be thousands of man-years of work.

> I like the idea of Semantic Versioning, but it does cause problems where if I'm going to do several breaking releases one after another I have to keep bumping the major version, and I hate that. I've actually put off doing breaking changes simply because I didn't want to bump the major version number, but I don't like that either.

When you're doing backend/API things (where breaking changes matter), I sure hope you think a million times before making breaking changes.

Can you imagine if someone had to go through millions of lines of his code to make sure nothing broke, then, a week later, you broke his code again?

>There's a reason why the project name doesn't change just because you bumped the major version number.

The OP suggested to make an "evergreen" Angular, like an evergreen Chrome. My point is that you can't do that if you introduce breaking changes, because "this will work in C (and just upgrade to a new version if you don't have it)" doesn't work anymore.

Obviously making small breaking changes shouldn't require renaming your language (so PHP4 is still PHP, even though it broke quite a lot of old files relying on register_globals)

>It's much more reasonable though: they're committed to using Semver, so even a minor breaking change (like upgrading Typescript) will bump the version number. So they're expecting the version numbers not to matter as much anymore, similar to how you no longer think of the version number of Chrome or Firefox too often.

That's contradictory.

Once you introduce breaking changes, you require people to update, and old code may not work on new systems.

Then you can't just say "Angular" like you can't say "Python" or "C/C++"