pjbk

I know that some guitarists hate them, but I enjoyed playing my stereo Marshall ValveState (a newer one with an ECC83 instead of the classic 12AX7). I think it was the right balance between both worlds. You could barely tell it was mostly transistors inside. Well, it was a Marshall after all. That being said I have played the new MG ones and you can feel there is something missing.

I once had to repair my circa-1990 Crate GX160, so I bought its schematics. Most of the passive components went into multiple stage filters on every freaking section. Talk about overkill. I doubt you could even hear the effect of some of those filters, but they definitely played safe and took care of designs back then. Except for a few vendors, now it's all about packing as much they can on the digital side and penny pinching on the hardware.

Oh, I thought the lines blurred quite a while ago and they are the same bunch now?

Same for guitars in those money brackets.

I think that, more often than not, they are part of the problem? Like favoring policies that promote spending and debt instead of long term investment and savings, in particular in those areas where it is really necessary.

Granted, but you can do the same and much more with different methods, and avoid fighting the frustrating, unreliable and time-consuming UML tools altogether.

Reminded me a bit to the classical NY Fed paper before the subprime crisis [0]. Each bubble is different as much as each bubble is the same. I guess the main invariant is that what goes up must come down at some point, because of "reasons" and principles of human nature on complex individual and group behavior. Usually those are only clear after the fact.

[0] - https://www.newyorkfed.org/research/epr/04v10n3/0412mcca.htm...

Crazy. Now that you say that, I honestly thought it was a parody even showing up here in HN. Took me a few seconds to realize it was not when reading the article, and had to watch part of the video to convince myself. But then again, most news these days read like an Onion article of yesteryears. Just sad, not funny anymore.

For me it was a slow progress. Takes a while to grab the paradigm shift and unwind some mental schemes if you are used to imperative languages and you want to start thinking in declarative terms in a way that you can be productive as a Prolog programmer.

That being said, learning about the inner workings of Prolog and how the WAM (Warren abstract machine) is composed helped me a lot to adjust my programming skills and align them to how things are best coded in the language.

We lost a bunch of excellent scientists, teachers and human beings overall, known and less known. Besides Barrow, it was personally painful to learn that Malcolm J. Skove also passed away last June. He co-authored one of the best introductory physics textbooks that I have read, "Physics: Classical and Modern".

Some of my acquaintances still use Bars'n'Pipes in the Amiga as their main to-go music composing MIDI software, since it's reliable, has a well-designed wide set of tools, and the minimalistic, clutter-free interface helps them stay focused and therefore be more productive.

Based on my experience, many, many, many headaches would be saved if this advice was followed more closely.

IMHO defensive techniques including recovery should be placed in runtime monitors and supervisors, not in underpinning code which should have a minimum set of behaviors. It should also be kept as simple as possible to avoid code bloat and help reviewers and tools like static analyzers do their job.

Old computing hardware was designed like that. Then software attempted to replicate hardware "exceptions", however not realizing that the model was intrinsically different and completely exploding in intricacies dealing with interrupts, stacks, memory management and threads.

In a similar way, supervisors should be as decoupled as possible from the target code to provide reliability and avoid overall system complexity, with their own set of narrowed down requirements.

Sadly our industry is plagued with historical, ad-hoc programming techniques that are not relevant anymore or were plain empirical bad advice in first place. For example, blindly relying on stateful paradigms, or side effects by design or as an acceptable consequence of certain programming idioms.

Unfortunately that is mainly the case these days.

In theory it would make more financial sense that most companies at the startup stage would be fully employee-owned, considering the equity and tax scenarios. But what founders are open to that? It amazes me that still there are/were people, myself included, willing to partake in a rigged endeavor plagued with pitfalls and restrictions, compared to other business models out there.

I've had to program some Android apps in the past, mostly internal or technical tools for scientific applications. Last time it was last year, and after struggling for a week to get old code run reliably using the latest SDK, I gave up and rewrote successfully the app with Qt and the NDK. Is this a viable solution for something that can be offered through the Google play store?

It's incredible that with the increases in processing power and storage technology, and the continuous performance enhancements of postgres in particular the last years, any "scalable by design" solution of 10 or even 5 years ago can easily be implemented in postgres these days. I guess the 80/20 rule applies more than ever in these cases.

I am far from a database expert, but the fact that I have been able to implement without much effort efficient systems that have high bandwidth and reliability requirements, balancing and low latency speaks eons of the current state of affairs.

I have been involved in embedded systems for more than 25 years now, and I barely do "pure" embedded development these days. That is projects that comprise only designing a specific PCB hardware, or writing the firmware drivers and top level application for them.

Except for a couple of years I have resided mostly outside of California, but when doing consulting I have mostly engaged with companies in the Bay area.

In the past when I did pure embedded development I had to fight tooth and claw to get rates close to $100/hour, while at the same time iOS app developers or webdevs were starting at $120-$140/hour easily, even after the mobile app craze. Despite taking into consideration that I am both a hardware and a software engineer, and rates outside of California were much lower ($45-$70/hour at the time). Which was one of the reasons I pushed hard to find my clients in the Bay area instead.

These days since I have more experience and business contacts I have diversified into more complex projects that have embedded components and pay me better since they belong to regulated industries. Even now I work with full-stack software programmers in AWS/GCP cloud apps, React/Vue frameworks, modern databases and connected middleware that make around $200/hour. For comparison, in the last years I have been involved in the development of a medical device where I did the hardware design (MCU/FPGA, signal acquisition), HDL/firmware programming (Verilog, RTOS, Linux, BLE), technical host tools (C++, Python, Qt) and was paid $180/hour, and lately a mobile robot project where I did the hardware architecture, integration and system control loops (MCUs), and prototyped the high level software application (RT-Linux, ROS, Nvidia Jetson) for $150/hour. An acquaintance in the valley that was working for a similar project but entirely in the ML/CV stack was billing $270/hour. That may be a bit extreme example since ML is hot today, but nevertheless.

In my humble experience, slightly less ≈ 30% to 40% less.

Quaternions are left handed, which is annoying but not a big deal by itself, but most importantly collapse the scalar with the pseudoscalar. For regular applications of unit quaternions in 3D euclidean space such as rotations, screw displacements and dual quaternions, that is not much of an issue since the scalar part is initially zero anyways (e.g. translation and rotations), it wholly contains the quadrature information after the operation (e.g rotation), or the scalar part is always separate from the vector quaternion (e.g. moments).

However if you want to see the quaternions as a vector subspace in problems of higher dimensions or in non-euclidean manifolds, for example path interpolation, finding integral solutions or representations, they fall short and it makes sense to use a Clifford algebra that is compatible with differential operations (e.g Lie) and gives consistent calculations across all dimensions.

> There are no interesting formulas in a tensor algebra, because the whole idea of it being “most general” (every other algebra is a quotient) is that it has no relations. It is only when passing to more specific algebras (symmetric, exterior, GA, ...) that the subject really becomes interesting.

And yet you can still go a level further, with objects like those in Moon & Spencer's holor theory that include generalizations for transformation rules beyond covariant or contravariant, generalized connections similar --for example-- to universal Christoffel symbols, and effectively creating rules for tensors, pseudotensors and stranger array-like objects.

The answer depends on the kind of Clifford/Geometric Algebra being used, the structure for the vector bases and the selected result of the quadratic forms. Those choices are mostly driven by the end application where the algebra will be used, with its similarities (obviously, they are all algebras) and particularities.

* "A brief introduction to Clifford algebra" - https://www.researchgate.net/profile/Giorgio_Vassallo/public...

* "Doing euclidean plane geometry using projective geometric algebra" - https://arxiv.org/pdf/1501.06511.pdf

* "Projective geometric algebra: A new framework for doing euclidean geometry" - https://arxiv.org/pdf/1901.05873.pdf

* "3D Motion from structures of points, lines and planes" - https://tubaro.faculty.polimi.it/Journals/Journal_2008_DA.pd...

* "The Construction of 3D Conformal Motions" - https://link.springer.com/content/pdf/10.1007%2Fs11786-016-0...

Perhaps that is happening already, and some of the events we have seen in the last months are not by our own making but fabricated?

I just uploaded a plaintext diff between Pinochet's original 1980 edition and the latest ratified Lagos version (updated August 2020 for the plebiscite). Quite interesting to follow the changes. The git tracking also has the 2005 version. Sorry for the Spanish.

https://github.com/pbleyer/ConstitucionDeChile/blob/master/C...

Git repo at https://github.com/pbleyer/ConstitucionDeChile

If you like Monkey Island and Ron Gilbert's work, there is an online event with Ron talking about the details of the game and its development this Friday:

https://www.eventbrite.com/e/the-secrets-of-monkey-island-30...

Thanks for the suggestion. Last time I had to use YAML I used StrictYAML instead which gave me more peace of mind. I knew that there were schema tools around, however I just put more checks in the validator to avoid adding extra dependencies. Next time I will definitely look into those.

Yes. It was an indentation issue. It turned that the parent list accepted an item with the same id, so it was a valid statement and the full thing seemed OK. However the data ended up missing from where it was supposed to be.

Looking back to the last decade, I cannot remember a single project I worked in that relied on YAML that didn't have at least one incident from its users or developers dealing with the files and messing up. Just some months ago a team I was working with lost almost a day on a misbehaving software module. After serious detective work it all came down to whitespace in a YAML configuration file.

I remember being pretty excited when I discovered YAML and even pushed its use in some projects trying to avoid the verbosity of XML. These days I will never trade accuracy for conciseness, in particular if its form relies on whitespace and there is not enough redundancy in the specs for consistency checks. Yes, syntax matters.

IMHO with modern architectures these days, and from the last couple of years in particular, if you start feeling the need for something like Yocto I'd rather use a full blown distribution like Debian or Arch Linux if its available for your platform.

I have tried Yocto through the years and deployed a bunch of projects with it. Although it gives you the sense that it has a more coherent environment than Buildroot, I find that it is difficult to maintain since it has too much unnecessary complexity for embedded targets, and sooner or later that ends up getting in the way and biting you back. Not enough visibility, which is crucial for embedded systems. More so if the systems have network connectivity and need to be properly secured.

It could be that I am too acquainted to Buildroot's pretty flat and its spartan, no frills architecture. With highly constrained devices that is an advantage. Automating configurations takes low effort, they build quite fast, and you can maintain testing and deployments easily with your own bash or python scripts. There are few places to fiddle with variables and you can easily assemble images on the fly or through overlays. Many times you just need to modify the configuration file and rebuild.

The last years I have been progressively using Buildroot along with docker. They complement each other well and you can create base systems and then grow them tailored to your application taking advantage of the docker incremental build system. I regularly maintain cross-compilation and qemu-based docker image toolchains for my target architectures that way. They can be recreated and tracked reliably, 100% of the time. I use them to build the application images or just augment them with a buildroot overlay with the extra files and then also deploy them remotely through the docker facilities.

Taken over by the humbugs of always that now are computer savvy... It was a matter of time.

Totally agree.

Being involved with FPGAs for 20+ years now, and Xilinx for the most part of it, I have witnessed the progressive decay of their software quality. The legacy Xilinx tools (Foundation) were far from perfect but at least useable -- and hackable to a degree if you needed to implement workarounds. Those were many times even suggested by Xilinx own employees that were easy to approach and responsive back in the days.

Altera Quartus was always better in terms of project organization and user interface, including their hardware tools. Third party software such as Synplify (before Synopsys bought their maker Synplicity) were light-years ahead, especially on the synthesis introspection and support for design and RTL troubleshooting.

People tend to justify the software quality and vendor lock-in because these are niche markets. I think that is a lame statement. You could tell both Xilinx and Altera, being "fabless hardware companies", treated their software departments as a necessary burden and not a critical part of their business model, which by de facto it was. The software started going downhill, progressively accumulating technical debt while it kept getting even more cryptic and expensive. I think they offshored a significant part of its maintenance in the last decade. Each release fixed bugs but astonishingly introduced very stupid new ones that a minimally decent software verification process should have caught.

Vivado is a mess. You can optimize your workflow digging down deeply with TCL scripts (yikes, its 2020!). However who has the time for learning their badly designed API and fighting with the quirkiness of their tools? I am amazed some of us use it in regulated environments where our tools need to be properly validated. I have had designs that take more than one day to synthesize, map and route. Having being bitten by some bugs and my own errors dealing with the cumbersome IDE, I always painfully go through all the logs of each step, and also many times recreate the project and rebuild just to check if the output is reproducible.

Did you see any evidence of slavery, as some documentaries mention or seem to show?

Funny how JTAG these days is synonym with in-circuit debugger. The original use of the port was to support IC interconnect testing, and for high density boards it still is. For external parallel and serial memories you can use the boundary scan registers to bit bang the pins and read the inputs. In fact, that was a popular way to program external memories on fresh boards if they didn't come with embedded bootloaders.

Even if you don't have the scan configuration file of a particular chip for your tool, they are very standard and easy to figure out. No desoldering required!