>so how do you get a privately owned train car and get it to the tracks or etc?
I think you wait in a remote bit of Nevada for a train to pass, and trigger a rock fall which causes the driver to slam on the brakes and bring the train to a stop just short of the rockfall.
Then, you and your posse jump out from behind some rocks and fire your revolvers in the air, and the driver sticks his hands up. There's much celebration, and back slapping as you discover the train also happens to have a massive amount of gold bullion on board.
The rest is a bit blurry, can't remember seeing what you then do, but it probably involves filing down the serial numbers on the frame or something like that?
> Having worked at a railroad, I will say it’s comically easy to steal a train, for instance. They all have the same key, which is basically just a plastic rod.
> The argument of the railroads is... okay, you have our train. Now what? You either go forward or you go backward, and we know where both those directions go.
Well if you're Tintin you'll use it to catch up with the train in front and when that doesn't work, accidentally blow it up... Tintin in america is a great parody of 1930's Midwestern united states and the gangster culture of Chicago.
They actually do get lost quite often. There’s quite a bit of law around ownership of rail, cars, requirements, and maintenance and who’s in control and who’s in charge. All those numbers you see on the side of it are part of the tracking to figure out where things are.
The bad guys are driving their train when a cop train shows up in the mirrors behind their train.
Cop walks up to the window and asks for their license and registration please. Another shootout occurs followed by a multi-track multi-train police chase, but everyone needs to stay on their respective train tracks.
Yeah, with those early machines it was inevitably about lookup tables, and producing the illusion of doing work which was otherwise impossible in the number of cpu cycles you had available. I did lots of this sort of thing for the C64, where similarly CPU cycles were short, and then you end up scratching around trying to find enough spare memory...
It's great to see people still exploring and pushing the boundaries of what these machines are capable of. Coding this on a more modern machine, getting the effect right, then back-porting to the Spectrum seems like a smart move and would have been a game changer during the prime of these machines!
Lots of commercial Spectrum games were coded on a 'more modern' machine, often an IBM PC with a better keyboard and a cross assembler to generate Z80 code.
This situation happens with plenty of compilers for plenty of languages. It's just software after all, we don't expect any software to be perfect, so why expect compilers to be perfect?
As for deprecating old C++, yes, I can see the appeal, but no, the community hasn't gone that route. C++ has always been a 'mix and match' approach, with different parts of the community using more or less of the language features, with the intention being that you can choose what to adopt when, and move older code bases forward (or not!) depending on individual concerns.
It's one of the C++ strengths, although it doesn't always feel like it.
And yes, people being able to use your code for whatever they want is absolutely more open than having restrictions on how/who gets to use it.
One other model that can also work well is to dual license as GPL + commercial, so people who want to publish their work can use the GPL license but you can potentially fund the project from license sales to closed source users using the commercial licensing option. I see this a fair bit in the audio community I work within.
>And yes, people being able to use your code for whatever they want is absolutely more open than having restrictions on how/who gets to use it.
Yes, this is why people should use free not open , and GPL is more free when you report to the entire community otherwise you are in the famous case from a story where an USAian was claiming "Amerika is the land of the free, we are free to own slaves"
If you link against GPL code, your code needs to be GPL compatible. There are some IPC based workarounds, but they are too annoying and slow in most cases.
The problem as I see it is that LLMs behave like bratty teenagers, believing any old rubbish they are told or read. However, their voice is that of a friendly and well meaning adult. If their voice was more in line with their 'age' then I think we'd treat their suggestions with the correct degree of scepticism.
Anyhow, overall this is an unsurprising result. I read it as 'LLMs trained on contents of internet regurgitate contents of internet'. Now that i'm thinking about it, i'd quite like to have an LLM trained on Pliny's encyclopedia, which would give a really interesting take on lots of questions. Anyone got a spare million dollars of compute time?
I was involved in writing ATC software in the 90s for a European country (the FATMI system for Finland), and they were definitely using paper strips at the time, and I believe the design did not change this. I wasn't involved in the flight strip printing though, I was working on SIDs and STARs, airspace sectorisation, that sort of thing.
It would be interesting to know how things have changed since then, as obviously nearly 30 years has passed since that system would have been commissioned!
Generally speaking, the db scale is very useful for many practical situations, and this is overlooked in this critique.
As have been pointed out, it's just a power ratio on a logarithmic scale, but this has many benefits, the main one being that chaining gain/attenuation in a system is just a case of adding the db values together. 'We're loosing 4db in this cable, and the gain through this amp is 6db, so the output is 2db hotter than the input'. Talk to any sound engineer and you'll do this sort of thing successfully without necessarily understanding the science, so that's a massive win.
I didn't get that reading the article. The author acknowledge that ratios are useful, but that there are specific problems in how we use this unit and how we picked and express the reference scales.
> On the face of it, the idea makes sense.
Your specific example is a pure ratio so there's no problem with it (there is no reference). Apart from the fact that I have to guess whether you are measuring volts or watts through your cables, of course...
So what I learned today, via another comment and confirmed with a dictionary, is that decibels (unspecified reference) is NOT pure ratio - it's a _power_ ratio. So it will be Watts, not Volts.
But that's why it's so confusing. Did they purposefully leave off the reference to indicate Watts, or did they mean volts (as I'd guess audio engineers typically do when talking about amplifiers).
> this has many benefits, the main one being that chaining gain/attenuation in a system is just a case of adding the db values together. 'We're loosing 4db in this cable, and the gain through this amp is 6db, so the output is 2db hotter than the input'.
I'm not a sound engineer, so to check my understanding: would this not be the case for any other scale indicator?
If you have a cable that loses 4m and you're sending 6m into it, you'd not get 2m out?
(The m being milli here, as in millivolts or whatever unit would be useful here — leaving it unspecified to keep the comparison to dB as close as possible)
No, because db is logarithmic. That's the key property that allows you to do addition instead of multiplication. Remember these are ratios here as well.
So the original example in linear units would be: We're reducing the signal by 63% in the this cable, and the gain through this amp is 199.5%, so the output is...
If you look at professional distributed audio systems (Dante, AES67 etc) you'll find that they all require PTP support on the hardware to achieve the required timing accuracy, so yes, you need <1ms to get to the point of being considered suitable if you are doing anything which involves, say, mixing multiple streams together and avoiding phasing type effects.
However, it very much depends on what your expectations are, and how critical your listening is. If no one is looking for problems, it can be made to work well enough.
I think you wait in a remote bit of Nevada for a train to pass, and trigger a rock fall which causes the driver to slam on the brakes and bring the train to a stop just short of the rockfall.
Then, you and your posse jump out from behind some rocks and fire your revolvers in the air, and the driver sticks his hands up. There's much celebration, and back slapping as you discover the train also happens to have a massive amount of gold bullion on board.
The rest is a bit blurry, can't remember seeing what you then do, but it probably involves filing down the serial numbers on the frame or something like that?
reply