JSON Patch uses JSON Pointer (RFC 6901) to address elements, but another method from (very) roughly same time is JSON Path [0] (RFC 9535) and here's one of my favorite mnemonics:
- JSON Path uses "points" between elements
- JSON Pointer uses "path separators" between elements
To me, Loos' argument comes across as some grand rationalisation for a simple difference in taste. I.e. "I don't like it, but to state my opinion as a fact, I came up with this story about efficiency"
"Why do you waste all that effort (on something that I, personally, don't enjoy or benefit from)?" is an argument I read between the lines all to often …
> Loos made ornamentation sound like something practiced only by primitive peoples or criminal deviants.
Loos didn't make ornamentation "sound like" something practiced only by primitive peoples or criminal deviants. That was his main point. His argument is
1. We're more evolved than primitive people.
2. Primitive people, degenerates, and criminals ornament themselves and their environments.
3. Therefore we've evolved beyond the need to ornament our selves and environment.
A simple difference in taste doesn't quite capture Loos' racism. Loos attempts to build a reality where he and un-ornamentalists are more civilized, cultured, and morally superior to others and ornamentation is evidence of such. He uses ornamentation to construct a difference and then uses that difference to validate his superiority.
Loos' argument rests on othering "primitive people" and makes makes six total references toward the Papuans to accomplish this. It's short so I'll list each one.
1. Comparing them to children - "At the age of two he[the child] looks like a Papuan"
2. Describing them again as immoral children - "The child is amoral. So is the Papuan, to us."
3. As cannibals - "The Papuan kills his enemies and eats them."
4. As a reckless ornamenter - "The Papuan tattoos his skin, his boat, his rudder, his oars; in short, everything he can get his hands on."
5. Again compares them to children, and implies they are degenerates - "But what is natural for, a Papuan and a child, is degenerate for modern man."
6. That "we" are more progressed than primitive people. - "People progressed far enough for ornament to give them pleasure no longer, indeed so far that a tattooed face no longer heightened their aesthetic sensibility, as it did with the Papuans, but diminished it."
I can't stress enough how childish Loos himself comes across in the piece. It's a temper tantrum of an article and I'm honestly surprised it's taken seriously, or at least was. I'd encourage folks to read the original[1]. It's a five to ten minute read.
Not just efficiency, but degeneracy and criminality. The article fails to mention his own degenerate sex crimes, however. Much of his own work is not devoid of ornament, and ironically these works stood the test of time, in my opinion. His oversimplified work may have been startling in its day, today it looks bland next to the many many utilitarian buildings that followed this trend. Reduction inevitably leads to conformity. A cube looks like a cube, no matter who specified its dimensions.
I am also 30 or 40 years old. I'm Schrödingers millenial.
I quite enjoy the delivery of technology connections. A nice change of pace imo, compared to other youtubers that edit out every millisecond of quiet time between words and sentences.
But I'm not watching the videos to learn new stuff either
I think what turned me around was positive feedback. IMO the best way to get positive feedback is by being around the right people. You know … open hearted, welcoming folks, who talk to you and know how to listen and ask questions that get you talking. Once I realised that people can actually be interested in what I'm saying, meeting new people felt way less scary.
Now, it might seem difficult to seek "the right people" out yourself, so maybe ask acquaintances to take you along and maybe make introductions so you don't have to break the ice yourself. Something like "Hey, this is dondraper36, he's into X, you told me something about that last time didn't you" can be enough.
I can't understand how someone would recommend the gym. Just like you, I'm not awkward in the gym, but I'm not interested at all in conversation when I'm there.
Location: Aachen, Germany
Remote: Preferably
Willing to relocate: Maybe later, but happy to come for regular office visits anywhere between Amsterdam, Berlin, Frankfurt, Zürich
Technologies (recently): JavaScript, Java, Infrastructure-stuff, …
Résumé/CV: jpo.dev/f/cv-hn-2022.pdf
Email: hi (at) jpo.dev
Hi HN, I'm Jonas, and I'll keep it short:
I'm looking for something interesting in fintech or fintech-adjacent (if that's a thing).
No blockchain business please. (exceptions possible, CBDC comes to mind, …)
I consider myself a "full stack engineer", but shudder a little at that word. Tech stack is secondary to me, pretty much comfortable with every reasonable technology you throw at me. Mostly motivated by making things happen. I value good communication and would love a role that's "not just programming". Maybe some DevRel? Maybe get a chance to do open source at work again? Just some ideas ;)
Degree in Computer Science and 15 years of experience in software engineering. Mostly in fintech, though the earlier years were "no fin, mostly tech".
Plenty of hobbies besides tech, to keep me entertained.
We have a number of open positions including Software Engineers, Fullstack, Front-end, Product Designers/Managers, Data gurus and iOS/Android experts. shane.sale.ext@getmoss.com
I don't know. I totally agree on the premise that developers should be involved in ops as well.
But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space. (Insert joke about the CNCF technology landscape map.)
There's just so many tech/tools/etc. involved that just reasonably "doing the ops stuff" on the side seems way unrealistic.
Sometimes I feel that all we've accomplished was job security for legions of consultants.
> But I'm a developer by heart and my heart aches whenever I see what we devs have wrought in the ops space.
At the same time, I am conflicted. I don't care for the toss-it-over-the-wall approach that used to be the norm, but I also don't like having dev's have to take more on than they are capable.
In an ideal environment, I would like to see a crashing together of developers and operations people on teams. What I mean is that for a given team you have several developers and one or two ops folks. This way there is less of an us vs them sentiment and teams can be held accountable for their solutions from ideation to running in production. Finally while it's not the sole responsibility of the dev's to manage their DevOps stuff, they will have more knowledge of how it works, and get to put input and ideas to it.
This was the original intent of DevOps - a cultural shift that put sysadmins/ops people into the dev team, thus have a better feedback loop between dev and prod, and tear down the wall between dev and ops. But now it's being used as a way to eliminate ops people and push it all into dev.
Also, more about the aspect of collecting, rather than listening to music: discogs.com
If you're a collector, digital platforms like discogs give you access to a way bigger market. (And I imagine there's something like that for pretty much everything one could collect.)
I think I spent more time browsing discogs than any physical record store, even before those were forced to close their doors due to the pandemic.
So, they only use the physical connector not the … uhm … transfer protocol associated with memory modules? Tbh, at least with memory, I always conflated both.
If there are multiple vendors around SO-DIMM SoCs, is there a common standard for how they are using the pins?
> is there a common standard for how they are using the pins?
None that I'm aware of. Considering some pinouts I've seen my guess is that different vendors simply assign them as they see fit. Also, especially ARM SoCs have widely varying capabilities, and different SoMs have all kinds of different hardware on module/off module, different bus systems they support, and so on. Also, some SoCs can change some of their pin assignments to a degree. Given all that and considering that the whole purpose is usually to cheaply develop semi-customized embedded hardware for specific applications, there might not be much demand for that either.
One thing about the memory bus is that it is a perfectly good bus for devices. You absolutely can put something like a computer into a memory socket and use it as a device. You simply latch onto a particular memory address that's not going to be used for memory and whenever you see that you know the memory bus is for your device.
I don't know if this is merely form factor compatible or an actual device for a SO-DIMM memory socket but there really isn't anything stopping you making a DIMM socket peripheral device except the need for external power.
Huge difference between memory bus in front of memory controller vs behind it. You cant just plug yourself into a DIMM slot and act like a device on a memory bus. You will have to perfectly emulate particular ram supported by your memory controller (protocol, access patterns, timings), and this will be strictly a slave affair.
> If there are multiple vendors around SO-DIMM SoCs, is there a common standard for how they are using the pins?
Not really. If you want a common standard with multiple vendors, look at COMexpress and Qseven, with the former sporting everything up to Xeon CPUs and the latter low-power (12W TDP, iirc) only.
JSON Patch uses JSON Pointer (RFC 6901) to address elements, but another method from (very) roughly same time is JSON Path [0] (RFC 9535) and here's one of my favorite mnemonics:
- JSON Path uses "points" between elements
- JSON Pointer uses "path separators" between elements
[0] https://en.wikipedia.org/wiki/JSONPath