alblue

> The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere

For what its worth, Windows 3.x did not come with a TCP/IP stack installed; it was an optional extra. (In the days before Windows 3.x you had to pay for the TCP/IP stack from your network card vendor as an optional extra.)

It wasn’t until Win95 that the OS came bundled with TCP/IP by default, and you could still install other networking protocols like Novel Netware or AppleTalk.

TCP/IP didn’t become the default stack until late into the ‘90s and the “everywhere by default” wasn’t really true until just before the turn of the millennium.

So while QUIC might be in the “early adopters” space for now, everything started that way once. I have no doubt that by 2030 we will see QUIC as a kernel feature in many major operating systems.

You can get the qnx do floppy from archive.org:

https://archive.org/details/qnx303

Cadbury’s chocolate used to be a British company (having started in the Bourneville area of Birmingham in the UK) but was taken over in 2010 by Kraft, the American makers of spray-on cheese from a deodorant bottle.

The problem is that American chocolate is something of the worst in the world, and so there’s no doubt that the (cocoa) bean counters negatively affected the Cadbury brand and taste in order to shave off a few cents.

https://www.bloomberg.com/graphics/2019-opinion-cadbury/

Siri’s voice translation works in your phone but the answers it needs are all calculated from the server (on the whole). Maps, for example, are all stored server side and route calculation are server side processes as well, as are the locations of restaurants.

There’s a difference been decoding voice requests and being able to answer any questions you may have; you wouldn’t expect Google web search or Wikipedia to work in offline mode, so why do you expect it to work for Siri?

You don’t need to do it every time; you only need do it once per application. It’s a privacy feature that prevents an application being able to record your screen (or use your camera/microphone) without your explicit knowledge and permission.

And frankly Zoom just works, and works well. What advantage would using a random site with an unheard of record possibly give you?

The problem is there’s too much to be shown in a hierarchical navigation.

If you can’t remember what you need then looking it up with :helpgrep (or just :helpg for short) and then type in part of a word of what you are trying to do.

https://vimhelp.org/helphelp.txt.html#%3Ahelpgrep

It’s at the bottom of the description:

The presentation was recorded at the London Java Community meeting in April 2020, and a recording is available here: https://youtu.be/C4HEoBYL0yk

I gave a presentation last year on this for QConLondon (before the lock down) and afterwards for the LJC virtually, if people prefer to listen/watch videos.

https://speakerdeck.com/alblue/understanding-cpu-microarchit...

If you were starting from scratch, you probably would start with a different system. However web objects was their web framework at the time which was ported from objective c to java decades ago and shifting legacy from any technology to another is practically impossible especially if that technology is a cost rather than a product.

Yes, but while web objects was a first class thing in the objective c world back in 1995 the direction swung due Java from about 1997 onwards — I doubt there’s any non-Java WOA any more. For example, it was developed when 32 bit PowerPC was a thing and I don’t think it ever made it to 64 bit Intel.

I worked there, and yes, most of the server side stuff is in Java and Go.

If you’re interested in writing safe shell scripts then check out shellcheck:

https://github.com/koalaman/shellcheck

If you’re interested I’ve written a git hook for it that runs a check when you git commit:

https://github.com/alblue/scripts/blob/main/shellcheck-pre-c...

You should also check out her Google shell script style guide:

https://google.github.io/styleguide/shellguide.html

Given the italics, it wouldn’t surprise me if the original was in fact:

sizeof(*(void*)1)

I wrote my own tool for this which allows you to fix up a file based on the last time you changed that file, or on a specific commit. It will then execute an interactive rebase to that point as well as taking care of stashing and then restoring unrelated files.

https://github.com/alblue/scripts/blob/master/git-fixup

I like the idea of having the editor definition return “true” instead of showing it; I’ll have to add that later.

You can use “git clone” for that; it will set up an alternates link in the local clone, so you only store the git object data in the origin but apply deltas to the clone.

It’s a good piece, but needs a (2017) on it.

Absolutely. Plus, and organisation can do dumb things because a single wrong person in the hierarchy of such a system can make a bad decision that takes hundreds of man years to undo.

The reason small startups can innovate faster than large enterprises is that they can’t afford to make stupid mistakes. There’s no such evolutionary pressure on enterprises, unless it until the scale of the stupid mistake becomes life threatening for the company.

That’s because it’s a single organisation. Just because it is made up of tens of thousands of individuals doesn’t stop it being a single entity.

You (and all other humans) are made up of thousands of bacteria and other specialised cells, but we don’t treat you as plural, although you are also a single entity consisting of tens of thousands of components.

You can go into the accessibility panel in system preferences and increase the contrast and remove transparency, both of which aid readability and interaction.

Over yet last few years the WiFi daemon insists in writing content to the /var/log/wifi.log and friends, and there’s no way of turning it off.

TL;DR Gradle and Android users are likely to be most impacted, since a lot of their tooling has directed users towards JCentral in the past.

While JCentral is a strict superset of Maven Central, it means that there are some libraries/tools that are present in JCentral which will disappear. Given the short notice period (end of April 2021) it's likely this will take people by surprise when it happens, and at that point, there will be no way of recovering the libraries that you depended on to build your Gradle and Android projects.

What’s interesting is that this is both the magic code for Java class files, and also for Mach-O executables on NeXTstep and macOS. So the language that inspired Java also has the same magic number — although this is a coincidence, not a derivative.

Me too :-)

https://twitter.com/alblue/status/1266322655604588544?s=20

I interviewed Mike Milinkovich about the VAJ->Eclipse transition in 2013:

https://www.infoq.com/interviews/Milinkovich-past-present-fu...

I was involved using Java right from the very start, in 1995 while it was still available as a beta.

I remember being distinctly annoyed that the Java 1.1 broke the model introduced in Java 1.0, in which a JVM which had no Windows showing or Threads running would terminate automatically. When Java 1.1 was created, the event dispatcher thread was created (incorrectly, in my opinion) as a non-daemon thread, which meant as soon as you loaded the toolkit the JVM would never close until you hit System.exit. Here's the bug I proposed a fix with in November 1998:

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4030718

The shutdown hook never got fixed; these days there's convenience methods to add a shutdown hook to the (J)Frame so that on close it would call System.exit for you.

I've written a bit more about my history here if you're interested:

https://alblue.bandlem.com/2021/01/java-1.0-turns-25.0.html

I interviewed Mike Milinkovic who led that team and who became Eclipse's executive director back in 2013, if you're interested in a trip down memory lane:

https://www.infoq.com/interviews/Milinkovich-past-present-fu...

Yes, prior versions were insanely buggy. 1.0.2 was pretty stable as they fixed most of the problems by then, although Java 1.1 was when companies started to really use it for stability. Problems happened with the windows fork which was pinned to 1.1.3 but it went up to 1.1.8 IIRC.

Java bytecode allows for Debug attributes, which are produced by default in most build engines, and say which field maps to which item on the stack and for how long. Even if that information is removed, the fact that you have the return value of an invokedynamic called `object.getName` means that you can often have a much better chance of redeeming the information than in other compiled languages.

The key difference is that fields and methods maintain all their names in the bytecode; in C, non-public symbols are usually stripped leaving only the calls to libraries present.

No, it's likely that it won't be quite as disruptive in the future. There were a few backward incompatible changes with modularisation (in order to break module cycles) but the bigger disruptive changes were moves away from sun.misc.* packages which should never have been used by production code (but which often were, because speed).

Fortunately Java took a middle-of-the-road approach; it didn't quite get rid of as many things as it could (Unsafe stayed around in a few ways). Had it all been killed off then the transition would have been more problematic.

With Java 17 being the next LTS I don't think there's appetite to break things before then but it's quite possible that Java 18 will really put the hammer down and remove Unsafe for good. That, I think, will be one of the last disruptive things Java does.

I gave a presentation on bytecode and class loaders if you’re interested. The deck is at speaker deck and there’s a link from there to a recording I did for the LJC if you prefer me narrating it:

https://speakerdeck.com/alblue/bite-sized-bytecode-and-class...

What's even more interesting is that C++ and Objective-C started around the same time, and while one is known about widely, the other is still used heavily in the macOS and iOS ecosystems today. Indeed, the creator of Java acknowledged that Objective-C inspired the Java runtime, in particular its late-binding and message sending capabilities, which is what Java has used to this day to allow applications to still run unchanged, even after all these years.