The amount of times the data can be read out per second (the sampling rate) and the accuracy (bit depth) are limited for obvious reasons

Interesting post. I wanted to highlight this part where you say it’s limited for “obvious reasons.” It’s probably better to explain that since it might not be obvious to folks trained to think transistors are free, the CPU’s are doing billions of ops a second, and everything is working instantly down to nanosecond scale. “How could such machines not see and process about everything?” I thought. What I learned studying hardware design at a high-level, esp on the tools and processes, was that the digital cells appeared to be asleep a good chunk of the time. From a software guy’s view, it’s like the clock signal comes as a wave, starts lighting them up to do their thing, leaves, and then they’re doing nothing. Whereas, the analog circuits worked non-stop. If it’s a sensor, it’s like the digital circuits kept closing their eyes periodically where they’d miss stuff. The analog circuits never blinked.

After that, the ADC and DAC tutorials would explain how the system would go from continouous to discrete using the choppers or whatever. My interpretation was the digital cells were grabbing a snapshot of the electrical state as bit-based input kind of like requesting a picture of what a fast-moving database contains. It might even change a bit between cycles. I’m still not sure about that part since I didn’t learn it hands on where I could experiment. So, they’d have to design it to work with whatever its sampling rate/size was. Also, the mixed-signal people told me they’d do some components in analog specifically to take advantage of full-speed, non-blinking, and/or low-energy operation. Especially non-blinking, though, for detecting things like electrical problems that can negatively impact the digital chips. Analog could respond faster, too. Some entire designs like control systems or at least checking systems in safety-critical stuck with analog since the components directly implemented mathematical functions well-understood in terms of signal processing. More stuff could go wrong in a complex, digital chip they’d say. Maybe they just understood the older stuff better, too.

So, that’s some of what I learned dipping my toes into this stuff. I don’t do hardware development or anything. I did find all of that really enlightening when looking at the ways hardware might fail or be subverted. That the digital stuff was an illusion built on lego-like, analog circuits was pretty mind-blowing. The analog wasn’t dead: it just got tamed into a regular, synthesizable, and manageable form that was then deployed all over the place. Many of the SoC’s still had to have analog components for signal processing and/or power competitiveness, though.

Even though I learned about the Fourier transformation in University this video gave me a new intuition: https://www.youtube.com/watch?v=spUNpyF58BY

Thanks very much for your detailed reply :). The math doesn’t scare me, it’s just very rusty for me since a lot of what I do doesn’t have as much pure math in it.

I appreciate the time you put into it.

Speaking specifically of Fourier transform: it behaves well for infinite signals and for whole numbers of periods of strictly periodic signals.

But in reality the period usually doesn’t divide the finite fragment we have (and also there are different components with different periods). If we ignore this, we effectively multiply the signal by a rectangle function (0… 1 in the interval… 0…) — and Fourier transform converts pointwise multiplication into convolution (an operation similar to blur). Having hard edges is bad, so the rectangle has a rather bad spectrum with large amplitudes pretty far from zero, and it is better to avoid convolution with that — this would mix rather strongly even frequencies very far from each other.

This is the reason why window functions are used: the signal is multipled by something that goes smoothly to zero at the edges. A good window has a Fourier transform that falls very quickly as you go away from zero, but this usually requires the spectrum to have high intensity on a wide band near zero. This tradeoff means that if you want less leak between vastly different frequencies, you need to mix similar frequencies more. It is also one of the illustrations of the reason why a long recording is needed to separate close frequencies.

I never really understood why short release cycles is a problem for people, but then I don’t use Debian because of their too long ones. For example, the majority of Firefox’s releases don’t contain user-visible changes.

Could you elaborate what your problems with Firefox on Debian are? Or why software lifecycles can even be hostile to you?

I can’t see any non-scifi future in which we give up on chemical rocketry. Chemical rocketry is really the only means we have of putting anything from the Earth’s surface into Low Earth Orbit, because the absolute thrust to do that must be very high compared what you’re presumably alluding to (electric propulsion, lasers, sails) that only work once in space, where you can do useful propulsion orthogonally to the local gravity gradient (or just with weak gravity). But getting to LEO is still among the hardest bits of any space mission, and getting to LEO gets you halfwhere to anywhere in the universe, as Heinlein said.

Beyond trying reuse the first stage of a conventional rocket, as SpaceX are doing, there are some other very interesting chemical technologies that could greatly ease space access, such as the SABRE engine being developed for the Skylon spaceplane. The only other way I know of that’s not scifi (e.g. space elevators) are nuclear rockets, in which a working fluid (like Hydrogen) is heated by a fissiling core and accelerated out of a nozzle. The performance is much higher than chemical propulsion but the appetite to build and fly such machines is understandably very low, because of the risk of explosions on ascent or breakup on reentry spreading a great deal of radioactive material in the high atmosphere over a very large area.

But in summary, I don’t really agree with, or more charitably thing I’ve understood your point, and would be interested to hear what you actually meant.

What physical effects would be used?

I think that relying on some new physics, or contiguous objects of a few thousand kilometers in size above 1km from the ground are not just a paradigm shift; anything like that would be nice, but doesn’t make what there currently is a disappointment.

The problem is that we want to go from «immobile inside atmosphere» to «very fast above atmosphere». By continuity, this needs to pass either through «quite fast in the rareified upper atmosphere» or through «quite slow above the atmosphere».

I am not sure there is a currently known effect that would allow to hover above the atmosphere without orbital speed.

As for accelerating through the atmosphere — and I guess chemical air-breathing jet engines don’t count as a move away from chemical rockets — you either need to accelerate the gas around you, or need to carry reaction mass.

In the first case as you need to overcome the drag, you need some of the air you push back to fly back relative to Earth. So you need to accelerate some amount of gas to multiple kilometers per second; I am not sure there are any promising ideas for hypersonic propellers, especially for rareified atmosphere. I guess once you reach ionosphere, something large and electromagnetic could work, but there is a gap between the height where anything aerodynamic has flown (actually, a JAXA aerostat, maybe «aerodynamic» is a wrong term), and the height where ionisation starts rising. So it could be feasible or infeasible, and maybe a new idea would have to be developed first for some kind of in-atmosphere transportation.

And if you carry you reaction mass with you, you then need to eject it fast. Presumably, you would want to make it gaseous and heat up. And you want to have high throughput. I think that even if you assume you have a lot of electrical energy, splitting watter into hydrogen and oxygen, liquefying these, then burning them in-flight is actually pretty efficient. But then the vehicle itself will be a chemical rocket anyway, and will use the chemical rocket engineering as practiced today. Modern methods of isolating nuclear fission from the atmosphere via double heat exchange reduce throughput. Maybe some kind nuclear fusion with electomagnetic redirection of the heated plasma could work, maybe it could even be more efficient than running a reactor on the ground to split water, but nobody knows yet what is the scale required to run energy-positive nuclear fusion.

All in all, I agree there are directions that could maybe become a better idea for starting from Earth than chemical rockets, but I think there are many scenarios where the current development path of chemical rockets will be more efficient to reuse and continue.

What do you mean by “chemical rockets are a dead end”? In order to escape planetary orbits, there really aren’t many options. However, for intersteller travel, ion drives and solar sails have already been tested and deployed and they have strengths and weaknesses. So there are multiple use cases here depending on the option.

Yeah right after we upload our consciousness to a planetary fungal neural network.

My own hunch is that we should be avoiding impure operations like getting the current time.

This post seems to be talking about trusting high-assurance languages for critical/sensitive tasks, and how those guarantees can be undermined if we run arbitrary machine code. That problem seems too difficult to me: surely a better langsec approach would be for the arbitrary code to be in a high-assurance language, with the only machine code we execute coming from trusted critical/sensitive programs?

I would think a langsec approach to e.g. preventing timing attacks in Javascript is to make Javascript (the language) incapable of timing. Or, at least, providing a logical clock (also used for the interleaving of concurrent event handlers) rather than allowing access to the actual time.

Don’t forget to describe your constraints along with your goal. Otherwise you might get very unhelpful answers.

I imagine that Kodi’s user population is difficult to measure. I have seen Android HDMI sticks that ship with a custom Kodi build enabling users to browse various streaming media repositories. It’s a fascinating ecosystem that seems to be largely invisible to people in the American Netflix/Hulu world.

Seconded. Until reading this headline, I had never heard of it.

I haven’t yet finished reading the post, but what strikes me is that the points of the book “Debt: The first 5000 years” are quite relevant. There has always been some form of forgiveness between closely knit social circles. But this breaks down at scale and we need systems that are resilient against free riders, while still allowing forgiveness.

One thing that has made me skeptical about block chains as a big source of change is how often hard forking comes up and/or happens. ETH has been hard forked to deal with a bug. Bugs aren’t going away any time soon. So is this decentralized blockchain actually valuable if you’re still going to have people doing hard forks when something happens they don’t like? I just don’t really see humans wanting to be in an artificial prison when it harms them.

my problem with PowerShell is it’s always locked down so I cannot use it productively, that, double clicking, and no middle button pasting means Windows is just a frustration to use, for me :~(

I have used PowerShell on a few occasions but still very much prefer the Bash that comes with the Portable Git install on Windows. Although Bash might not be the best shell, which I don’t have any opinion about, it is quite usable, having sensible tab completion and history support. In addition, PowerShell often requires you to write multi line scripts for tasks that are easily achieved by a one-liner in bash.

PowerShell doesn’t really feel like a shell in the sense of being designed for interactive use. It may well be a fine programming language, but it’s just too verbose to use as an actual shell, IME.

Same technique I’ve always pushed. I liken it to an economic version of redundancy in hardware. We know it can go wrong in any number of ways. We make sure we can switch over without losing our data or computations. Should do choice of software similarly where possible. The prevalence of open API’s, formats, and code helps a lot with that these days.

Thanks for the correction, I’ll go tweak the summary of Beekum’s argument.

This easily leads to not using the features of the smaller competitor. The smaller competitor needs to give me a risk mitigation strategy, being able to switch away is just one, another one may be having the source available in some shape or form. Maybe there are even more that I cannot think of now.

Project Fortress (a programming language research project) proposed mathematical syntax for programming:

Mathematical syntax The idea of “typesetting” the code using LaTeX has received mixed reviews, and many potential users find the issue of keyboarding the extended Unicode character set daunting. Nevertheless, even in its more verbose ASCII form, the syntax of Fortress, especially the notion of treating juxtaposition as a user-definable operation, has proved to be very convenient.

I have used unicode greek characters in my code, which I find very helpful, especially when doing scientific programming. My colleagues didn’t like that however and the toolchain was complaining too.

That was really insightful. Thank you!

I am not an acme user, but I considered trying it. What I always wondered about with those self-made commands. Are there like collections of them? I know they aren’t hard to make, but I think a collection could give you ideas, starting points, etc., kind of like a vim plugin or config. Even if I don’t go with huge packages usually (be it vim or zsh), I kind of like ideas that you find while looking at existing stuff.

Or is that generally discouraged for some reason and never fell important?

Holy tag batman! ;)

It might be silly and small, but it is still cool.

More interesting than my early programs in QBASIC as I was learning. Don’t worry about how amateur work look to others: just keep learning, building, and improving. :)

I agree that git is awful to learn, but removing staging seems unnecessary. Even worse, they use funky flags where git uses commands, and they did away with push/pull in favor of publish/???.

I’m not impressed. I’ll stick with git and will continue to teach people how to use git instead of some seemingly better shell.

I’m perfectly happy using mercurial, which doesn’t have a staging area. Whenever I use git, I get annoyed because it has this extra useless concept. Mercurial has “hg commit -i”, which is analogous to “git add -p”, to commit only a subset of the changes to the working directory.

git gui is my prefered way to use git. Gitg/gitk/cola are also invaluable. Github client was good originally, but thry simplified whioe also some how maing it harder for me to use.

I think git add -p is an invaluable tool.

And it gets even better with Magit, if you’re an Emacs user

drawing out the commits as a graph on the whiteboard.

Whether one thinks this is a good thing or a bad thing is a pretty accurate litmus test for git appreciation.

I envy you because I want to understand git’s ASCII graphs but even after years I cannot wrap my brain around what they mean and how they would “look” in a 3D space. I find that last bit is necessary for me to understand conceptual graphs.

It’s pretty poor behavior, agreed.

I look forward to the point where I have the option of literally not owning it (that is, access to a cheap on-demand service instead of putting down the capital up-front).

I feel like we lack good words to express the cultural upset of discovering that ‘ownership’ and ‘control’ are no longer the same thing (and may never be again).

There is a far more important reason to support Tesla though: climate change. Tesla is the only reason the automotive industry is (unwillingly) shifting towards EVs, but it’s far from a done deal, so continued success of Tesla is necessary until the shift to EVs is complete.