That might have been me! There were one or two M stations there. I heard a couple of stations calling CQ. Very difficult to pick out signals without any filtering.
Very cool. It does get a bit chaotic when there are a number of people keying. If there was the ability to add a narrow filter then it could be usable for a QSO (radio contact)!
There are some other apps designed for having QSOs - VBand[1] and Vail Repeater[2].
Finally if you want to learn to use morse code on the air check out Long Island CW Club[3]
> The problem was that Emine's cell phone was not localized properly for Turkish and did not have the letter <ı>; when it displayed Ramazan's message, it replaced the <ı>s with <i>s.
So it was the wife's phone that changed the meaning of the message, not his.
You didnt have to go out of your way to provide another excellent example of someone making themselves look silly by making a dumb comment backed by the wrong assumption, but I appreciate the cover.
Also a Nix/NixOS user/contributer. I feel like Nix+nixpkgs could become the universal packaging solution adapted to build deb, rpm, etc packages.
Through nix-env it even already has the idea (albeit discouraged) of imperative package management like apt.
Having spent a while with NixOS, running containers for user applications seems like using a cannon to kill a fly. The 'simple' alternative is to drop FHS altogether - which containerization is kind of doing in a roundabout way by isolating the app filesystem from system fhs.
As for it being for developers only... I get that perspective. Debian/Ubuntu packaging is also hard, AUR packaging has its quirks. A lot of this is hidden behind the package manager, wheras with NixOS it is more obvious.
The killer idea for NixOS would be to make package management for Joe Q Public as easy to use as apt while. Tools like MyNixOS[1] are emerging which might bridge that gap.
The one advantage Flatpak provides for me over Nix is containerisation. Not the bullet-proof kind, which allows you to run malware, but of the "reasonable" kind, which stops apps from storing to any directory they like just like that (only chroot level of "security"/isolation would be fine for me).
When there's a package manager / runtime that does both then I'm extremely interested.
It looks... somewhat abandoned, but I'd wager it still works today. Failing that, setting up a shell alias to launch a regular binary in bubblewrap isn't too hard either.
It's a long standing goal of mine to put together a distro with the system management aspect of NixOS, the isolation of bubblewrap and the lightness of Alpine. I'm gonna start this project when I have time™.
Agree with the final part of this article that "programmable" configuration languages like Nix and Dhall are the way forward.
I've spent a lot of time writing YAML for Ansible, Cloudformation, k8s, Helm, etc. Some of the issues this article mentions are pitfalls but once you get a bit of experience with it, you know what to look out for.
I've also spent and a lot of time writing Nix expressions, which is much more "joyful" IMO. Seemingly simple features like being able to create a function to reuse the same parameterized configuration makes life much easier.
Add in a layer of type safety and some integration with the 'parent' app (think replacements for CloudFormation's !GetAtt or Ansible's handlers), the ability to perform basic unit tests, then configuration becomes more like writing code which I consider a good thing.
I expect that aftermarket firmware would be an issue for content providers. For example, is Netflix going to allow third party firmware developers to create an app to access their content? They will already have contracts with content distributors like Lionsgate that mandate DRM in their own apps to prevent piracy.
If your aftermarket firmware doesn't support Netflix, Prime, HBO, etc then it might have limited appeal. Browser based apps might get around that in a limited way.
As for printers, I think of them as loss leaders to generate ink sales.
Don't know either space particularly well so might be wrong.
Yeah, I wondered about the Android situation; Android itself is semi-standard, in that once you get the hardware support and a way to run your image it's not too hard to build AOSP for nearly any phone. On the other hand, that bit about getting a way to run your own ROM is, on average, awful and device-specific. Still, I suspect that it's better than TVs that run completely different OSs to start with. Edit: Oh, and AFAIK a lot of those OSs aren't FOSS in the first place, which makes things harder; at least with Android the vendor is legally obligated to give you the kernel source and then you can stick that in AOSP and probably get a working image. Other than WebOS, I don't think TVs have an equivalent.
Agreed that content support and DRM are a difficulty.
I know that the ink price gouging is part of why printers are weird, but that results in the default firmware being user-hostile in a way that I would have expected to make people want aftermarket firmware all the more. I suspect that the difficulty there is also something about fragmentation and perhaps a lack of devices that even try to be open (Google publishes all the documentation and source to build AOSP for a Pixel phone; I'm aware of zero printer vendors doing so).
If the aftermarket firmware doesn't support Netflix, then users will have to choose between not having Netflix and having the features the aftermarket firmware enables.
If that aftermarket firmware enables better playback of pirated content, and the Netflix catalog deteriorates more and more with time, it's more and more likely that of the people who'd consider alternative firmware in the first place, more and more will decide against Netflix in that scenario.
Not that that may be enough people for Netflix to care, but it could easily be enough that "no netflix" is no longer a blocker for acceptance of the alternative firmware.
I wonder if it is possible to generate a ROT8000 quine, that is a phrase like "hello world" which yields a semantically matching phrase in some other language?
I've seen a lot of embedded Forth stuff recently but I don't get the appeal. Clearly there is some benefit over writing assembly, but why is it preferred over portable C, or even higher level languages such as Python on more powerful mcus?
FWIW I felt the same way about LISP for a long time until I fell in love with it via Emacs. So please educate me!
Forth is not just another language for the sake of it. I am currently learning Forth from Leo Brodie's excellent books "Starting Forth" and "Thinking Forth". It actually changes the way you think. Just as Lisp does - almost a feeling of "a new planet swims into his ken".
The main feature of the Forth style is to write lots of 1 to 2 line functions, in such a way that at the high-level, you have essentially a domain-specific language that looks like exactly what you want a program to look like - for example, "RINSE WASH CYCLE SPIN STOP" for a washing machine program, and "RINSE WASH RINSE WASH CYCLE SPIN STOP" for an extra clean option.
People claim that once you learn Forth, you start programming Forth-style in other languages like C, Python etc. I can already see the appeal.
My C sometimes looks like Lispy Erlangish weirdness, and my Java often looks like my C. Certain languages just have certain ways of worming their way into your brain and improving the way you think, much to the dismay of everyone who can't think that way yet because the idiom isn't native to that language (yet).
I love that effect. My JS changed a lot once I grokked LISP, and I finally understood why there was a Haskell course on my degree track.
One of the most rewarding training experiences was giving my old Haskell textbook to a junior team member and watching his (at the time .NET, w/LINQ) code change over the course of a few weekends.
I don't have recent experience with Forth, but traditionally, Forth didn't require such a "beefy" machine as a C programming environment.
For instance here's a fairly complete Forth environment in around 10 KBytes running on an 8-bit home computer. There was no C compiler at all for that machine, and if there would be, working with it would be a lot more hassle than a Forth REPL.
Aw, input is broken on mobile (Android + of course Chrome).
I'm getting a keyboard popup, and I appear to be typing somewhere offscreen (I can see a typing suggestion containing exactly what I've typed, which wouldn't happen if input wasn't going anywhere), but the text isn't appearing onscreen, then when I press Enter, I get an "OK" as though I'd hit Enter on a blank line... and the input I'd typed isn't cleared. So, "words <Enter> words <Enter>" shows "wordswords" in my keyboard's suggestion, and "OK\nOK\n" on the display.
Yeah no useful mobile support unfortunately. Plan is to replace the standard virtual keyboards (which don't have the necessary keys anyway) with a custom-rendered keyboard eventually.
Forth has a REPL, and tiny Forths like this can work on microcontrollers that are unable to host a Python instance. (A microcontroller that can run Python is pretty rare).
Otherwise, your development cycle in C or assembly is "peer at datasheet, carefully enter bitwise arithmetic, compile, flash, wait several seconds for flashing to complete, debug."
* Forth is tiny. You don't need a preprocessor, a compiler, a linker. Your entire programming environment, beside the text editor, can live directly on the target MCU.
* Forth is interactive. You can run your code, examine the results, define and redefine words, run again, etc right on the target machine (which may be a tiny controller). Yes, you likely will remove the REPL-related words from the final image (or not), but C can't hold a candle to the interactive development experience of Forth.
* Unlike in C, you can build an economical DSL in Forth to closely match your target domain. What Forth takes away in readability due to the need to think in stack terms, it more than pays back in expressiveness and abstraction, provided certain skill and taste.
While Forth does have an execution overhead and thus cannot obviate C completely in some cases, I've seen e.g. an injection controller for an internal combustion engine which did hard realtime completely in Forth. Hard realtime here means that all computations were clocked by the rotation of the shaft, with precise timing of different phases along the way.
C normally involves compiling the entire program at once. Even if you use a interpreted C of some sort, C is a lot more verbose and involves more typing.
This is important when testing and evaluating new hardware. All you need is a serial port or equivalent connection to a forth to allow you to exercise the hardware in a very interactive way. In some cases you might end up writing the final program by accident.
Through a certain lens, a vanilla Forth program is defined purely by composing pure functions (and those compositions are vastly easier to write in Forth vs C or Python). It's a simple idea that has a lot of elegance, giving you high-level properties in a language that can be very close to the metal.
73 de G4IYT :)