The "one phone call" is a myth made up by Hollywood. Last time I was arrested, there were several phones in the holding cell, and I was there for four hours. I could make as many phone calls as I wanted, to anyone, either local or collect.

I don't think it was a myth so much back in the day - the supreme courts ruled that if you were arrested, you have a right to contact someone. I.e., the police could not arrest you, then toss you in jail without you being able to talk to someone who can try to do something about it.

Perhaps it's more apt to the smaller communities, you know, the ones where the cops are just as crooked and looking to arrest you for any reason whatsoever. The one phone call came into play saying you were at least to have the right to contact someone - otherwise the police would just lock you up for a month, then set you free.

In most "normal" areas, yes, the phone is freely available for use because the last thing anyone wants is for you to be let go because you did not have sufficient time to contact someone, especially an attorney.

So today it's more likely a myth, but back maybe 50 years ago, it probably wasn't. Plus probably a bunch of court precedent that basically said under what conditions that "one call" really meant (is it one call, and if you reach a busy signal, no answer or an answering machine and that's it?). Just safer to let them have use of the phone as much as possible so no lawyer can get the guy off because he was denied sufficient phone access.

This product doesn't appear to be outside of the realm of the possible; bulk metallic glasses are a real thing (and apparently not excessively expensive for consumer electronics, a number of Sandisk's adequate-but-cheap-and-wholly-unexciting MP3 players used them as chassis materials); and the rest of the specs are on the high side; but available.

However, there appears to be almost nothing about this 'Turing Robotic Industries' except a couple of sites with the same 3d renders and vague puffery. Is 'cryptic' just what all the cool kids are doing these days, or is this the ever delightful scent of vaporware?

I suspect these guys may be an industrial manufacturer or some form or other, where a webpage is basically whoever can host web pages for free and who use gmail for email.

Given Apple just renewed their exclusivity to use Liquid Metal technology (in consumer electronics), someone's going to be in a world of hurt.

Could be these guys may be forced to license through Apple, Apple may demand damages from Liquid Metal for allowing this to happen, or Liquid Metal might terminate the contract with these guys.

Might want to hold off on the pre-orders...

They probably just ran into a million issues on OS X and its implementation of OpenGL and Apple doesn't give a shit.

I also never heard of DX11 on OS X. I imagine he must be referring to Bootcamp, although I don't know the state of Apple's drivers for bootcamp.

I guess they could have just not released the game in the first place instead of pulling it later...

No, they basically recompiled their app using a Windows API library.

There are lots of Windows API libraries - like WineLib - where you take your Windows source code, compile against the library and you have a Mac/Linux/Etc. app.

Square used Cider, which is an older port of WINE (before WINE switched licenses because TransGaming was effectively selling WINE without contributing back)

And no, there is no "DirectX for OS X". There's a DirectX API provided by the library that runs on top of OpenGL. Basically they're hoping the next release of Cider will have improvements in the Windows API library.

But it still will run like crap. Because it's a Windows game that runs on a Windows API emulation layer that runs on top of OS X. So of course, when you add in the library, it's no wonder performance on OS X sucks - OS X is running a virtual Windows API layer.

The reverse is also true - iTunes/QuickTime are notorious offenders in the "runs like crap" category, because they do the same thing - Apple has an OS X API layer that runs on Windows, and it's that OS layer that iTunes runs on.

It's simple. As long as a significant portion of Apple's revenue comes from having a closed, "walled-garden" ecosystem, Apple will be disinclined to participate anything that might result in the demise of that ecosystem. After all, it's hard to be in the same boat as everyone else supporting WebAssembly etc., when that same technology will ultimately result in the death of on-platform app stores.

Apple's walled garden and iTunes revenue pales in comparison to their iPod revenue, which has been declining for 10 years straight. (It's roughly on order of a billion dollars). Just to compare, Macs account for several tens of billions of dollars. And iPhones/iPads account for hundred billion.

Apple's take from iTunes is small and not essential. Unlike Amazon whose business model IS to sell content, Apple's model is to provide content, to sell hardware.

Oh yeah, iTunes content sales include music and movies as well. (Apple does not break it out any finer grained than that).

Anything Apple does is to sell hardware - that's their main revenue generator. Everything else is just icing. Especially to encourage sales of new hardware.

Safari upgrades don't sell hardware.

You know, I think since this court case, eBook prices have actually gone up. I mean, when we actually had Amazon, Barnes and Noble and iBookstore competing, you could get books for $10. Now that iBookstore was colluding and banished as a competitor, damn has prices risen.

Yeah, Apple sucks, blah blah blah, but now we have less competition and Amazon's dictating the pricing rules. I don't think the ebook market is as healthy as it was back then, nor as competitive... especially now with Barnes and Noble on life-support, iBookstore gone, it's just Amazon...

Not only that, but no artificial limit to g. No pilot to keep conscious.

Easier to scrap the airframe and design for a drone, actually. Because too much has been done already in the design to support a pilot.

If you're not having a pilot, there's a TON of equipment that can be gotten rid of because you don't need life support equipment, all the cockpit gear, even the canopy can go.

And with all the extra space you make, you can fit more armament and all that in there.

I asked this because I do not accumulate those in a business setting. In our office we have the printer service companies (who beat each other up to get our business) deal with that, but they do not do private households and I am not bold enough to just dump my empty cartridges on the pile. I am sure they'd catch on to that quickly because we only have HP at work.

They probably will accept them.

They don't do private households in that they won't do business with you. They are often more than happy to take empty toner cartridges for recycling (really, refilling). And the worst that happens is they leave it in the area, so check it after they're through. Hell, if you're scared, ask IT if you can leave your toner carts for them.

If not, I'm sure there's a walmart or other place with a ink/toner refill business. They'll be more than happy to accept empty cartridges that they send back and refill and sell in the store.

Hell, the online retailer you buy from probably has a buy back program.

This is also a trademark law maneuver.They must defend their trademark, and unfortunately, a lawsuit is the only way that the courts will recognize it. If they didn't, then anyone could use their non-response to the workbetter domain name as evidence to take their trademark.

Except the domain was registered BEFORE the trademark.

That's the key point - if the domain was registered AFTER the trademark, then yes, trademark law is clear on that. But in this case, the trademark was created long after the domain was registered.

So it's no longer a simple "defending a trademark" procedure, as otherwise it opens up a whole legal way to expropriate property. Don't like a domain? File a trademark and if successful, sue to get the domain, doesn't matter who got it first or whatever.

It's similar to the case where the guy got his YouTube URL taken away just because someone with money wanted it. Or Nissan.com - the original owner had the store way before the car company renamed themselves.

Trademarks need to be defended, however, defense implies preventing people from diluting it. It doesn't cover the case where someone else already uses the name prior to your filing. (And there are many trademarks that are similar - as long as their trade areas don't overlap, that's fine.)

((Asked then answered: it is bloody hard considering the physics of the game means that any given offrails object is under precisely one sphere of influence at any given moment, which means that until the SOI changes (from the Sun to Kerbin, for instance) you know where the rock is and where it's going - but the second the SOI changes, all those napkin calculations you just did for an unguided nuke shot just went right out of the window))

Well, the math gets really hairy otherwise once you have more than two bodies to consider.

Newton's gravitational formula is only specified for two objects. If you have more gravitational bodies, the math turns into a really nasty set of differential equations which practically speaking can only be solved numerically.

So depending on the simulation, either they'd try to do it numerically (which imposes resolution limits since now your time step is very important), or you simplify the physics and try to avoid the issue.

If you're using GPL code, you have no choice but to release your code under the GPL as well.

But only if the GPL code can mix.

The FSF has agreed that GPLv2 and GPLv3 are fundamentally incompatible - GPLv3 imposes additional restrictions that conflict with GPLv2. So you have to be extremely careful when mixing GPL code together.

Basically, v2-only code (GPLv2) cannot touch v3 (GPLv3) code, and vice-versa. If you have v2 code, then make sure it is licensed as v2-or-higher (GPLv2+). The resulting GPLv2+ and GPLv3 code will form a GPLv3 work (if the GPLv3 code was GPLv3+, then it's GPLv3+).

And that's where mixing code gets really dangerous.

Personally, I dislike GPLv3, so I dual license my code as GPLv2 and BSD-3clause. GPLv2 means it says v2 (I don't license it under v2-or-higher), and the BSD 3 clause is inherently GPL incompatible. So the dual license means you can use it with GPL code (as a GPLv2 work, meaning no GPLv3 code can be included), or obey the 3 clause BSD and use it however you feel like it.

Yes, I sleep at night. If some company wants to take my work and use it, good on them. My issue is GPL folks who say "BSD lets companies steal your code" without admitting that GPL does the same while also saying GPL is superior because it doesn't allow it. Sorry, but locking BSD code up as GPL is exactly the same as companies locking up BSD code. Saying your license is superior because it disallows others from doing the same while doing it yourself is disingenuous. More than one BSD project has been unable to get back contributions from "superior" GPL projects because doing so will mean accepting GPL code.

Or you could wash the wings once in a while. You're on the tarmac for over an hour while:
      - Passengers are busy boarding despite their boarding group not being called.
      - Crews are not loading your luggage.
      - The pilot is working on his second cup of "sober up" coffee.
      - The flight attendants are gossiping about who fucked whom.
      - Etc.

Might as well have a guy spend 2 minutes hosing off the wings. Impact of build-up during a single flight surely falls below the point where applying and maintaining a fancy coating is cheaper than having Jose hos-e off the bugs.

Bug guts are sticky. They do not simply hose off. You need to actually scrub them off, and if you're doing that, you need skilled labor because there are lots of sensitive things that stick out of aircraft.

More than one aircraft has been lost because someone missed removing some tape covering some hole or other that was applied in order to wash the aircraft.

And there's a lot of surface to scrub, too.

Even little bug smashers like Cessnas take a good while to clean off (and flying through a bog meant you often flew through a crowd of mosquitos, so the leading edge was covered in lots of little red spots).

The real solution is to NOT use a generation algorithm for keys. Generate strings, then approve only those you actually sell and distribute.

Hash collisions will eventually happen. I believe Windows XP suffered from it where the sheer number of installations has meant that there was a good chance a keygen will also make a valid key that's already been issued. Sure you are blocking a good chunk of them at the beginning, but eventually a keygen will stumble upon a valid key that you DID issue.

I believe it also happened to a widely pirated game - the end result was legitimate users were getting locked out because the publisher created a huge list of keys (and the server checked it was issued!), and the keygen created keys on the list as well, so pirates could play the game, while the key was sitting in the box on the shelf at Best Buy. User comes around and boom, key is used.

To expand on this... you should also generate an "Installation ID" upon validation, stored server and client side along with the key.

This prevents users from trying to activate the key on more than one system, and allows you to offer controlled multi-system installs if you so choose.

On update you validate both the key, and the installation ID.

In the event a user needs to move the software to another install, you can contact the licensing dept and revoke the previous installation ID.

The problem with that is users hate calling for support, and how long are you going to maintain it?

I mean, great, you do this. Now you'll have to handle calls from people calling about a 10 year old version they need moved to a new PC. And forget about offering in-system deregistration because most users, by the time they install it, the old installation is gone - either hard drive died, got corrupted, etc., and there is no way to deregister the key.

So either you have to deal with users who call to move their 10 year old copy of software (no longer supported) to new PCs (and hell no they will not pay to upgrade) even though it's no longer in production, supported, and bugfixes stopped 5 years ago, or you will end up with a really pissed off user.

You also have to remember we're talking about $20 pieces of software. If it was a $500 piece of software then maybe you'll have more diligent users who will tolerate phoning software support, but likely not.

For something like Malwarebyte's product, since it's online only, it's easy to check keys since it will have to get updates always.

Fwiw, Netflix pays big money to try and make sure it does interest you.

That's because of business model.

Netflix gathers a TON of statistics about who their subscribers are. Right now, they're mostly upper middle to middle class people who generally have professional style jobs and university degrees and all that.

Why is that important? Because Netflix's revenue source is subscribers. So they have to produce and obtain content that appeal to their subscribers. You're not going to see the latest exploitive TV show on Netflix if it's not appealing.

The goal if Netflix is to weigh the balance - who are the people likely to subscribe? Who are their current subscribers? If they produce content, are their current subscribers likely to leave?

Appealing to the lowest common denominator works for network TV, because those people are eyeballs and network TV is all about eyeballs. (If you want free TV, stick an antenna on the roof. Network TV still produces TV for free).

But those eyeballs even if you put the content on Netflix are unlikely to become subscribers. So it's pointless for Netflix to produce those shows because it'll attract few subscribers.

And yes, it's all about balance - is the Netflix subscriber base ready for a show about homosexual people? Maybe, if their subscriber base is more liberal, and they know that liberal minded people are more likely to pay for subscriptions.

That's the sort of decisions that go into Netflix programming. Netflix is not about eyeballs, it's about subscribers, and knowing their preferences. It's also about knowing their demographic - the people who would subscribe but currently don't, so knowing more about them to produce programming they like to encourage them to subscribe.

But that's not the same decision making that goes into CBS, NBC, FOX, ABC, and others, because they don't have subscriber counts, they have raw eyeballs.

The problem most Greeks suddenly face is that their money is now locked up as electronic balances in banks that have shut down for a week and won't let them have more than 60 euros at a time. After crises like this (even America's own "great recession"), people tend to prefer forms of money are more than just bits or fiat paper, such as gold and silver.

Greeks aren't stupid.

They're withdrawing their money now while it is in Euros. Not gold or silver, but Euros. Because if/when Greece exists the Eurozone, they may return to drachmas. And those Greek bank accounts that were holding Euros? They'd be converted automatically at some set rate. So one day the machine will spit out Euros, the next day, it's drachmas.

And Greeks know that if they switch back, drachmas will be basically worthless because no one will accept them.

It's not the Euro crashing in price (the market has pretty much priced that out already), it's whatever currency Greece uses next. It can be tree leaves for all anyone cares.

So Greeks are causing a huge run on the banks because at least their money is safer in Euros than it is in drachmas, tree leaves, Zimbabwe dollars, etc.

It's not electronic currency that's the problem, either - part of those whole 60 Euro a day thing also means Greeks can't transfer their Euros outside of Greece.

The Greek public isn't stupid. They know their country is in trouble, and they also know their life savings will evaporate in a pinch once they leave the Euro. That's why they're withdrawing Euros as fast as possible because the Euro will have value. The government will force-convert all existing electronic balances at some rate.

To put it another way - let's say you have USD$2000 in the bank (not in the US, but your country happens to use US dollars). The economic conditions are such that the government will probably go to a new currency because the US dollar is too expensive for them to maintain. So what do you do? Do you wait it out so your government will turn your bank account from US dollars to worthless scrip? Or do you try to withdraw all your US dollars because that will likely have more value than whatever scrip comes out?

In most failed countries, the default currency will be either the Euro or the US dollar, because the local currency is worthless. Zimbabwe is an extreme example of it.

Stupid, stupid, STUPID! Why have numRows and numCols in a sparse array? Things with unnecessary, arbitrary bounds annoy me. My implementation of Conway's Game of Life runs on a sparse array precisely because that allows the world to stretch arbitrarily in any direction a glider goes, limited only by the capacity of the bignum library and the total store available to the program.

Easy. How do you test that you're handling boundaries correctly?

I mean, yeah, your bignum goes from negative infinity to positive infinity. But what happens as you approach those numbers?

Also, how do you test that you're not arbitrarily limiting the results? More than one program has been caught in the 32-to-64 bit transition because they cast pointers to uint32's. (Enough that there's "uintptr_t" which is an int type big enough to cast a pointer to).

So why not have a way to arbitrarily limit the size? Even better, add in the ability to adjust the boundaries. That way you can do testing on small, easily testable and quickly reproducible array sizes and nail down the most common bugs you'll encounter (especially ones that require wrap around handling), before you run more extensive tests.

Plus, constants can be changed. One common test would be to change numRows and numCols and rebuild/re-run the test and make sure it handles the new value successfully and that it still works. You know, to make sure values like that aren't hard coded. (You may laugh, but enough people code "C:\Windows", or "C:\Program Files", to matter. It's basically assuming a constant will stay, well, constant, instead of checking. Apple threw Square Enix for a loop because Apple renamed the documents folder for storing volatile per-app content. Square Enix hardcoded their paths (despite Apple telling people HOW to do it properly), resulting in app breakage. Even worse, Square Enix's solution was "do not upgrade your phone/tablet". Apple threatened to withdraw their apps because of complaints, and within a week, new versions were released).

So yeah, you may use bignums, but maybe someone internally decided 32 bit ints were good enough, because well, it's a test app and no one was going to actually run it long enough to verify. (Funny, in production, how often people hit limits we think are "too big"... see IPv4. Windows' 49 day bug, etc).