mikko-apo

Nokia's then CEO's Elop's "burning platform" memo leak in 2011 seemed to hurt Nokia a lot by painting their existing and upcoming phones as inferior.

> I have learned that we are standing on a burning platform.

https://www.engadget.com/2011-02-08-nokia-ceo-stephen-elop-r...

Can you elaborate? Do you mean like the Promise API with the "spesialisti APIs"?

JDK21 has structured concurrency. It works with virtual threads so the main task will be moved aside (from the OS thread) until the sub tasks finnish.

https://www.infoq.com/news/2023/06/structured-concurrency-jd...

Before virtual threads, Java server would reserve a full OS thread while that code is being processed. OS threads use lots of memory and there might a limited number available. With a single incoming request or low traffic that is not a problem, but with many parallel requests the server would choke on using too much memory or OS threads.

Previously in Java if you wanted to avoid code that blocks the OS thread you would need to use callback based code or reactive programming: https://www.alibabacloud.com/blog/how-java-is-used-for-async...

Javascript moved on from callbacks to async/await, which colors the async functions and requires the programmer to be aware of the issues related to async/await.

For Java Project Loom takes a different approach. For example with server applications, the server would start running the code in a virtual thread and most of the code that looks like blocking will actually work like unblocking code. You get to use regular blocking code but you get async performance.

When the code needs to wait for a response, JVM can unmount the virtual thread from the OS thread and then the JVM can run another virtual thread in the OS thread. Once the response is returned and the OS thread is free, JVM can continue executing the original request.

There are some caveats to virtual threads. There is some overhead (but not a lot), some IO calls still block (but you don't get an indication about using blocking IO) and you might stumble on new kinds of bugs related to resource exhaustion (try reserving a million OS file handles).

But no more async/await, reactive programming, callbacks. Mostly just regular imperative blocking-looking code. I'm very excited about that.

I disagree, the success story has details that reveal lots on what's going on.

> The team uses software to prototype their instruments before implementing hardware designs. With the basic software platform already functional, developing the wavestate using Compute Module 3 took a fairly modest year

From that I would assume that software is developed on regular PCs and it took a year for them to get the software running on CM3 and hook up the CM3 to the two circuit boards and various systems. Which is super fast.

> The setup has two circuit boards. The main panel board contains all of the user interface elements, including display, buttons, knobs, wheels, and other synth-specific controls, along with MCU microprocessors to support them and communicate with the CM3.

Main board has all the physical buttons, knobs wheels, displays etc and MCUs are used to communicate with CM3

> The other circuit board has subsystems for audio, MIDI, the musical keyboard, and power, plus the socket for the CM3

The 2nd circuit board has D/A converters, midi connectors, keys and power and the CM3.

The CM3 is basically responsible for all the computations on the device. It gets inputs from various sources and outputs constantly digital audio to the DAC, midi to the midi out, data to the display etc.

I guess this would be the part where details would have been nice, but there's probably lots going on. How they ensure low latency function of the synth platform, how does the development process go, how does the CM3 integrate with the various systems. Each of those would be very indepth stuff, but imo the HN relevant part how they sped up the overall development of the platform and that is covered by the article.

Anyways, the cool part is how the three devices use the same hardware, so Korg can basically recycle both hardware designs, components and software from synth to synth. This speeds up development and reduces costs. Super cool.

Comparing that to how synths were made in the 80s, where you had to have a separate board per voice and replicate all the analog components between voices and keep their power usage and heat in control.

Thomann has nice pictures of the synths. The reuse is very obvious:

https://www.thomann.de/fi/korg_wavestate.htm

https://www.thomann.de/fi/korg_opsix.htm

https://www.thomann.de/fi/korg_modwave.htm

The insides of Yamaha CS-80 from 1977 (weight: 82kg) look a bit different

https://www.youtube.com/watch?v=_poihkLM5Go

Of course, with modern components a CS-80 clone (Black Corporation Deckard's Dream mk2) fits in to rack format and weighs only 4.5kg:

https://www.youtube.com/watch?v=BNf0kpidGc4

but the assembly of the DIY kit looks pretty painful:

https://www.youtube.com/watch?v=fk-pM2OBU1o

Only time when I noticed my fans revving up was when I went to a site that tried to mine some bitcoins.

Closing the tab reduced the cpu usage to normal levels.

Keeping the safety belt on protects other passengers too. A person weighing 80kg has surprisingly high amount of kinetic energy when the plane trashes around.

Kinetic energy is also the reason why the flight attendants try to lock as much as possible of the loose items to the overhead bins or under the chairs.

I don't know about Sweden, but in Finland the number of firebomb/grenade attacks increased a lot in the past few years. All of them due Finnish born right wing zealots trying to burn down the shelters housing the refugees.

Luckily there seems to be less attacks in the last half a year.

I think there's been more attacks, but here's a summary of some of them: http://yle.fi/uutiset/3-8517586 (Dec 2015, in finnish)

Actually with film it wasn't that straightforward:

"In the early days of color film, the color balance of the film’s processing chemicals were made with the primary consumer market in mind–which, at the time, was predominately light skinned individuals. “For many decades, chemicals that would bring out various reddish, yellow, and brown tones were largely left out,” explains the video’s narrator."

source: http://www.diyphotography.net/history-of-how-film-camera-tec...

The video has some pretty interesting details.

I think it's about balancing various things. Having less code is good unless there's a hidden catch you need to be aware of or it takes a few weeks to unravel what the code does.

I prefer code that is understandable right away, is consistent and doesn't have any surprises.

It's about the performance of selecting which function to call:

https://en.wikipedia.org/wiki/Dynamic_dispatch

Chrome displays if the browser is 64bit in its about box, but for Firefox that information is a bit harder to find out.

It's in about:buildconfig

We used Docker for the Hello World Open coding competition.

We provided CI for the 2500 teams and also ran the competition using Docker (both on top of AWS EC2 instances). I think that without Docker the implementation would have been a lot more painful and almost impossible given the time constraints we had for the project.

Fast starting and fast shutdown of build and test processes allowed us to run CI builds efficiently on a fairly small amount of nodes. This saved us money and also helped to keep the infrastructure manageable.

Also the additional level of security was really nice since we were running possibly malicious code from 2500 sources. The malicious part became even more evident when Kevin Mitnick tweeted that he might participate: https://twitter.com/kevinmitnick/status/446359450614378496

The Docker image repository was also really handy when we ran the races. We needed build the bots only once and then we could just use the prebuilt images on on race nodes.

Building the actual base image was fairly painful. We support about 20 different programming languages and also package in quite a few libraries. Once the base image build was fully automatized and we had the Docker related processes fully working, it was almost a revelation on how Docker could improve things over the classical virtual machine approach. I can't wait to try it out on another project :)

By the way, the competition finals are today (Tuesday) and streamed live @ https://helloworldopen.com/ (in English and Finnish)

Hi!

Unfortunately there's quite a bit of context behind those statistics that doesn't fit in to the title nicely.

I suspect that mentioning just HWO or Hello World Open or real time race car AI coding competition is not enough either. Do you have any suggestions on what would be a good title?

Actually back in 2012 Java wasn't that popular. Here's the language stats for the 200 teams 1.5 years ago:

  Ruby 28.4%  
  Python 27.5%
  Clojure 10.1%
  Java 9.2%
  CoffeeScript 8.3%
  Haskell 6.4%
  JavaScript 5.5%
  Scala 1.8%
  Go 1.8%
  Groovy 0.9%

This year Java rise and Ruby's drop are quite obvious when compared to the old stats.

I would image the complexity being really high because the game is about racing against other AIs. What do you think?

And I'm afraid local versions are out because:

1. players would reverse engineer the server's simulation code

2. we don't want to give access to other team's bots

Unfortunately due budget constraints we can't allow unlimited access to test game servers. Do you have an estimate on how many rounds would you need to evolve the algorithm enough?

Hi

Unfortunately due budget constraints we can't allow unlimited access to test game servers. Do you have an estimate on how many rounds would you need to evolve the algorithm enough?

Yes, we'll provide test game servers that you can use.

Hi!

Very good question :) The message protocol is synchronized because of latency. When the developers test their bots against the game servers, the server allows long response times. When automated races are run in the cloud (with low latency), the response times need to be more strict.

We're trying to keep the competition both fun and challenging so the simulation is kept fairly simple. More details will be revealed when competition starts.

During the competition the server code is not released. There are going to be game servers where developers can connect and test their bots.

We haven't discussed about what happens after the race. Lets see :)

There's nothing that makes internet somehow undo-hostile. But your observation about relational databases not having the support for undo is in the right track. Actually it can be expanded to most data storage mechanisms, sql, nosql etc. Out of the box many data storage systems don't support versioning and that guides the applications towards the "warn, overwrite, no undo" pattern. It's just a lot easier to do apps like that.

For many cases it would be better if the underlying data storage mechanism would support versioning. Image a CMS that's running on top of git. You'd have diffs, history, branching, merging, clones, tags and other very important features out of the box. Doing those features on top of a relational database is a lot of work, but with git you get them free.

Yes definitely, you're right. What I mean is that bad design or bad architecture can take months to fix while most editors can fix formatting automatically with a few clicks. At the same time I prefer my own projects to have very clear and consistent style.

I think the original poster (and the topic here) is using way too strong words for such an irrelevant issue. It's airbnb's project, they get have their own opinion. Their style guide won't ruin the Javascript community.

Also, the original poster seems to be on a mission of his own. He forked the project @ github, did a few modifications and changed the documentation in a way that conflicts with the original MIT license. Poisonous attacks like that are what destroy communities.

https://github.com/JacksonGariety/javascript/commit/e06e9a46...

Code style shouldn't change the value of code in any way. If it does something went horribly wrong :)

For me code's value comes from what the code does and how elegant the overall implementation is. Code's value definitely doesn't come from formatting or "style".

Hi

Cool, sysadmin at a research university sounds like a nice position to be at.

Yes, it's already on github. Unfortunately, since it's missing those critical features it's not easy to see how the whole system is going to work. If you to talk just drop me an email at gmail. mikko.apo is the account.

I've built a similar system, around 5 year ago. Users were able to deploy any version to any cluster from a nice UI. Basically you could select any version, click "Install" button and follow the logs in real time.

Behind the scenes it was a decentralized continuous delivery system. Very cool stuff, highly automated. Reduced a lot of work and sped up development cycles from months to minutes. Served quite a large software development organization (1000+). I think we had 1000 servers in 5 datacenters around the globe.

Nowdays I'm working on an open source version of that system, it's still missing few critical features but hopefully I'll get the first release out next spring.

btw, I'm looking for projects/contacts that would be interested in trying out how the system would fit their needs.