Programmers use it because the programming environments they work in use it. Notably Windows, .net and Java.

I wouldn't call it stupid. It was a way to add support for more characters to existing 16 bit unicode systems with minimal breakage.

Dunno what it's like in other places but here in the UK (which the OP mentioned) vehicles over a certain age (think it's 40 years now, it used to be 25, then for a long time the date was frozen) are counted as "historic vehicles" and don't pay any road tax at all. Afaict most ex-military vehicles run by enthusiasts fall into that category.

That should have said

Even the simplified formula of "leap year every 4 years" works for 1901 to 2099 which is from before the introduction of computers to beyond what most system designers would consider to be a reasonable system life.

Leap years and leap seconds are handled very differently.

The rules for leap years are according to a forumula that has been fixed for hundreds of years. Computers typically handle them as part of their conversion from internal "time elapsed since epoch" data formats to "human" date formats and otherwise don't care much about them. Even the simplified formula of "leap year every 4 years"

Leap seconds OTOH cannot be predicted in advance so you cannot realiablly convert "time elapsed since epoch including leap seconds" to "time elapsed since epoch excluding leap seconds" or "human datetime" for future datetimes and to do it for past datetimes requires an up to date list of leap seconds.

Then there is the problem that "time elapsed since epoch excluding leap seconds" which is a common way to represent time (presumablly due to the difficulty in converting "time elapsed since the epoch including leap seconds" to "human datetime" simply cannot correctly represent the times arround a leap second.

The testcase is also anything but simple, to test the code you have to inject fake leap seconds, but for a correct test leap seconds can only be injected at specific times (NTP for example increases it's update rate around possible leap seconds) so either you can only run the test at specific times or your entire test environment needs to run on "fake time". This is a big problem if your tests need to interact with a system outside the test environment in a way that depends on time within the test environment being in sync with time outside the test environment.

but then if you are working in integer space (signed or unsigned) then you can't really approach at all.for the idea of "approach" to make sense you need to be working in a space (e.g. the rational numbers) where you can get arbiterally close to something without getting there.

Punctuation outside quoted strings has some meaning but google often ignores the documented meanings because it thinks it knows better.

Punctuation and other non-letter characters inside quoted strings seem to be completely ignored.

I call BS

"alpha[beta", "alpha!beta", "alpha£beta" and "alpha\.beta" (the latter proposed by someone further down as a "soloution", clearly without testing it) seem to give much the same results (the little variation I did see was easilly within what could be explained by google's normal non-determinism), giving back mostly pages where the word alpha was followed by the word beta with any random punctuation or sometimes nothing at all in between

Searching for python "[" or c "{" gives many results that don't contain the symbol in question at all and even when the results do contain the symbol the search result doesn't highlight the text around it.

I conclude that google is simply unable to search for symbols and ignores them in it's searches, if you have evidence to the contary please post it.

git has it's own problems, in particular it has no good way to answer the.question "what code was in branch x of repo y at datetime x". Theres the reflog but that is considered more a disaster recovery feature than a proper history tracking feature.

Only if you approach from the positive side. If you approach it from the negative side then you get a limit of minus infinity.

IEEE 754 gets arround this by having positive and negative zero but that often seems like a cure worse than the disease.

It's generally a bad idea.

Some CPUs simply don't support generating floating point exceptions. Even where they are supported the details are likely to vary between platforms. In C programs you have to explicitly turn them on and libaray code may break if you do unless you turn them off before the library calls. Finaly a signal fundamentally means the CPU did a software interrupt that was handled by the kernel and passed back up to the program, it's a fundamentally expensive operation.

If you know your code will only be used on one platform*, you don't use library functions or you know the ones you use are fpe-safe and you know the case that will trigger the signal is really highly exceptional it might be worth considering, otherwise don't do it.

* And I REALLY mean one platform, for example vfpv2 supports them, vfpv3 made them an optional feature and in practice I've never come across a vfpv3 implementation that supported them.

Nothing is 100% secure. Some things are more secure than others.

Pen and ink signatures can be copied by a fraudster with sufficient skill at least to a level where a casual person would not notice. In many cases only the last page of a document is signed so earlier pages could easilly be substituted by a fraudster. I'm sure I also heard of attacks where a page was erased after being signed though I can't seem to find any references right now. There is also the issue of finding a good reference to compare the signature against.

Photocopies, faxes, scans etc of pen and ink signatures are worse. With a real peice of paper it's pretty hard to cut out the signature and paste it onto a different bit of paper without getting noticed. With copying involved it's much easier. A fraudster can get a clean copy of the signature (may involve a little bit of work taking a bad copy and cleaning it up but no particular skill involved), and paste it into a clean document. Since the document and signature are both clean there will be no visible "seam" to indicate the pasting. If grot is considered desirable to hide the digital origins of the document it can be added after the signature is pasted in by printing and rescanning.

I've seen at least one case where someone "signed" a document by pasting their signature into a word document and sending said word document to me. Doing the same thing with pdfs is even more common.

Cryptographic signatures have issues of their own such as verifying that the private key actually belongs to the right person, the risk of the private key being stolen, the risk of poorly generated or inadequate length keys being factored and so-on but compared to scaned/faxed/photocopied copies of paper signatures I would say they are far more secure.

I'd say it's a mashup of the two. Like java it has garbage collection*, like Java it represents strings as immutable classes which require a reallocation for any modification.unlike delphi which classically* uses refcounted strings and will in-place modify strings that have a refcount of 1. It has operator overloading which is something that java does not have and something delphi only added relatively recently*. It has properties like delphi and unlike java. It has user defined value types like . It uses a C/C++ based synatax (like java) rather than a pascal based syntax (like delphi). It has "delegates" which are essentially equivilent to the "method pointers" in Delphi, Java also added something similar but only very recently.

My big concern with mono is that they don't seem to have the resources to maintain it the same level that Java on linux is maintained to. In particular they implemented .nets main gui library windows.forms but then declared it unsupported. They were also very slow in adding properly working support for arm hard float systems.

* AIUI there is now a version of delphi for .net which presumablly uses .net conventions on these things.
**Disclaimer: I don't know exactly when delphi added it other than i'm pretty sure it was after the most recent version I used.

PEER - two transit providers who connect to each other (they are peers in the industry)

No,

PEER - two networks who connect to each other to provide themselves and their customers (if any) with access to each other and each others customers (if any). Those networks may or may not be in the buisness of selling transit on the open market. Google, netflix, the BBC and so-on all have plenty of peers.

ISPs who are in the buisness of providing high quality service to their customers (as many smaller providers are) and/or who have to buy transit to reach large parts of the internet (again as many smaller providers are) are motivated to peer as widely as reasonablly possible (obviously there has to be some threshold below which the administative cost of setting up the peering aren't worth it). Content providers are also generally motivated to peer as widely as possible.

On the other hand large monpolistic ISPs see a refusal to peer or deliberately shitty peering as a means to force content providers to become customers.

Which brings us to the root of the problem, the US has let ISPs get far too large through allowing vertical integration of last mile infrastructure with ISP service and through allowing cable companies in different areas to merge into a handful of monoliths. The FCC is trying to paper over the consequences without solving the real problem.

A few things to note about nintendo portable backwards compatibility.

1: They tend to drop support for games from older generations. The game boy micro and later don't support GB/GBC games. The DSi and later don't support GBA games.
2: The DS doesn't have a link cable port so while you can play GBA games you can't use link cable (or wireless, see below) in them
3: The DSi and later don't have a GBA style cart slot, so game features that rely on that slot (for example transferring pokemon from GBA versions) can't be used on the DS.
4: There is no hardware abstraction on the wireless. This means that a GBA game can't use the wireless on the DS at all. It also means only games that were released after the DSi can use WPA, older games are stuck with wep or no security.

Several things have changed over the years with electronics.

1: everything has got much smaller, as a general rule the smaller something is the harder it is to repair and the more vulnerable it is to things like tin whiskers,
2: there are a much greater number of specialist short lifecycle parts used nowadays.
3: hardware vendors have stopped releasing schematics for their products and the complexity of the boards has reached a level where noone is going to reverse engineer said schematics.
4: in the early 2000s the EU introduced RoHS and effectively banned the use of lead in new electronics (with a handful of exceptions). Even if you don't live in Europe you were affected by this as manufacturers decided it was more economical to have one RoHS compliant product for sale worldwide than have seperate EU and non-EU versions. Lead-free solders and component finishes are far more prone to whiskers and cracking than lead based ones.

The overall result of this is that newer hardware is often much harder to keep going than older hardware.

Having said that you do want to be careful and keep an eye out for problems. Afaict the biggest cause of "damaged beyond economic repair" in 80s hardware is when a memory backup battery leaks over the main PCB and this goes unnoticed causing severe corrosion.