I think I would be more willing to embrace this sort of tech if there computing resources were easily accessible to hack on.
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.
A problem with this from my point of view is that while hardware engineers did an incredible job increasing the processing power of our thinking rocks, us software devs did a tremendous job of squandering 90% of it away. Of course there also are market incentives for doing so (time to market, dev costs etc...).
Empirically it seems that software simply doesn't scale as well as hardware does. I feel like this overhead would make "smart dust" impractical.
Or I guess I could put it that way: one hand hand you could be impressed that a modern light bulb can run Doom, on the other you could be alarmed that you need a Doom-capable computer to run a modern light bulb.
It's interesting because I come from the exact opposite direction. I started with IDEs, then Emacs for almost 15 years, and last year I switched to Vim.
Ecosystems change all the time, even if you've been coding in C for decades chances are that you've dealt with a bunch of build and package systems over the years.
The more time passes the more I value ecosystem- and language-agnostic tools. Dummy completion, tag-based cross-reference (admittedly not completely language-agnostic, but close enough), find, (rip)grep, fzf etc...
No setup, no configuration, it's lightning fast and it just works.
I'm not arguing that my approach is better than yours btw, if you like more integrated environments then go for it. I just sometimes wonder if "kids these days" even consider that there's a world outside of Visual Studio and ultra-heavy language runtimes. The zen of a 10 line Makefile.
I recommend looking into gitolite, it's very simple and low maintenance and makes managing access a lot easier and with much more granularity than authorized_keys.
It's basically just a simple perl script and a couple configuration files. It just work in my experience.
If you end up scaling to the point where you have dozens of users and need to make regular changes to the config it becomes rather cumbersome, but for small groups of people (with a couple of build bots and the like that need read-only repo access) it's very well suited.
GDB is incredibly powerful but it really lacks some good tutorial, and some of its defaults are... questionable.
It's so heavily scriptable and configurable that you could argue that it's almost more of a debugger framework than just a debugger. I would argue that it's almost under-used really, simply because most devs don't realize what it can do besides setting a breakpoint and dumping a backtrace.
I'm looking at sway and it looks promising (although I wonder how it deals with the many weird corner cases that X11 tiling WMs have had decades to fix and work around) but Sway's home page linked to the wlroots project which is:
>[...] a modular basis for Sway and other Wayland compositors to build upon
I was curious to see what that looked like so I went on the github and the first sentence on the README is:
>Pluggable, composable, unopinionated modules for building a Wayland compositor; or about 50,000 lines of code you were going to write anyway.
My jaw literally dropped when I read this. It seemed so wild that I actually cloned the repository and ran sloccount myself to check if there was a catch (there isn't, master is at 53k lines). My DWM is 3k lines and it's fully featured as far as I'm concerned.
I realize that it just pushes a lot of that functionality (and code) into X but at least it separates the concerns, my WM doesn't ship with half of the X11 source code as a hard dependency. Also X11 has been battle tested for literally decades by now, it's not a fast moving project (well, arguably it's quite the opposite, hence the very existence of this discussion).
I haven't looked very deeply at Wayland so I won't say that they're doing it wrong, maybe I'm just missing an important aspect, but the more I learn about it the more it feels like they've thrown the baby out with the bath water.
X11 can be hugely hacky at times and some of it is seriously outdated at the conceptual level, but it also does many things amazingly well, arguably better than any other mainstream desktop environment out there. It's an incredibly flexible, if a bit idiosyncratic system. Wayland seems to fix some of its flaws by introducing a brand new system that comes with its own set of drawbacks.
Man reading this thread confirmed that I probably shouldn't even attempt to use Wayland in the near future, I basically use every single of the features you've listed.
So far I basically kept using X11 because it mostly just works for me, but I didn't expect that Wayland was still so far behind.
I'm personally concerned because I like to use "niche" tiling WMs (I used Ratpoison then StumpWM for over a decade, then I switched to a rather heavily customized DWM a couple of years ago).
Even with a relatively monolithic and "opinionated" protocol such as X11 it's not uncommon to encounter applications that don't play very nicely with alternative paradigms (because they expect a tray to be available, or to be able to place floating windows anywhere they want for instance). Still, overall with a few hacks here and there it works mostly very well. Basically I know that we're 2nd class citizens within the unix desktop world but at least the X11 model gives us enough of preemption to get things working mostly correctly.
From what I see of Wayland I'm very concerned in the long run. Not being able to just beat a window into submission X-style seems like it would create a world of troubles.
And because tiling environment are fairly niche I don't expect the ecosystem to organically evolve solutions to all of these problems.
And if you think "well just stop using tiling WMs and use whatever else is using you weirdo" please do note that these issues are also often the same that are encountered by people with disabilities who need to rig their UIs in certain ways to make them usable. Also you'll have to pry my tiling WM from my cold dead hands, you heathen.
>From what I see many techies are now aware and upset, and hardly anyone seems to want to defend Google anymore.
Be careful, most of us on HN are part of a very small echo chamber. "What you see" is a small, non-representative portion of "techies". If it wasn't Firefox wouldn't be at sub-5% in general usage surveys and AMP would've died years ago.
I agree completely, that's what's so messed up with this "freemium" model that's so popular these days. If companies need to develop the ad-ridden version with tons of tracking to monetize free users anyway, what's the incentive for them to turn it off for paying users?
It's not like 99% of them are going to care and/or notice anyway, and if anything it would be more work to test and maintain a different version of the code without trackers.
Just pay for the things you use people, and block everything you can with browser plugins. This model needs to die.
I'm not arguing that the kernel devs are doing it wrong. I'm only pointing out that, in my opinion, the way C deals with error handling (that is, by not doing anything at all) is far from reasonable and the cause of many bugs. It's terrible ergonomics.
If you have a kernel function returning a pointer and you think that you're supposed to check for NULL when it actually returns a ERR_PTR in case of errors you will not only fail to do the check but on top of that end up with a garbage pointer somewhere in your program. If you have a MMU and you try to de-reference the pointer you'll have a violent crash, which at least shouldn't be too hard to debug. If you feed the pointer to some hardware module or if you're working on an MMU-less system then Good Luck; Have Fun.
C doesn't have your back here. It doesn't let you signal how a function reports errors, it doesn't even let you tag nullable pointers.
If it's not that complicated please explain why OpenSSL, the linux kernel, Curl a multitude of very popular C libraries don't do what you describe. Clearly it's complicated enough that even talented C coders try to cut some corners when given the chance.
C error handling ergonomics are non-existent which means that everybody bakes ad-hoc library-specific conventions that are extremely error-prone.
You could argue that they're doing it wrong and you might have a point but if almost everybody gets it wrong maybe it's fair to blame the language itself a little bit.
>Handling malloc() failure is almost never done for short lived programs.
True, and that makes sense for something like git. But in my experience many long-lived programs don't bother to handle ENOMEM gracefully either.
But I guess I'm veering off-topic here, I'm mostly fine with applications crashing of their own volition when they don't have enough memory. I agree with you that in many cases there's no clear recovery path for an application that's out of RAM. It's the OOM-killer I have a problem with.
>While C has no special error handling mechanism in place, error handling can still be done reasonably.
I very much disagree with that. There are a few factors that make error handling in C a pain:
- No RAII, so you have to explicitly handle cleanup at every point you may have to early-return an error (goto fail etc...).
- No convenient way to return multiple values from a function. That means that in general functions signal errors returning some special value like 0 or -1 (even that is very much nonstandard, often even within the same library).
Oh you want to be able to signal several error conditions? Uh, maybe use several negative codes then? Oh you need those to return actual results? Well maybe set errno then? Don't forget to read `man errno` though, because it's easy to get it wrong. Oh you had a printf in DEBUG builds in there that overwrote errno before you could test it? Oops. Don't do that!
What's that, your function returns a pointer and not an integer? Ah, mmh, well maybe return NULL in case of error? You want to return several error codes? Well maybe you can just cast the integer code into a pointer and return that, then use macros do figure out which is which. It's terribly ugly? Well the kernel does it so... It can't be that bad right? Oh and what about errno? Remember that?
What's that, NULL is a valid return value for your function? Uh, that's annoying. Maybe use an output parameter then? Oh, or maybe some token value like 0xffffffff, that probably won't ever happen in practice right? After all that's what mmap does.
So no I wouldn't consider C error handling reasonable in any way shape or form. "Non-existent" is more accurate. You can always work around it but it always gets in the way.
I try to always implement comprehensive error checking in my programs. I do a significant amount of kernel/bare metal work, so it's really important. It's not rare that I end up with functions that contain more error-handling-related code than actual functional code.
>Most programs just aren't very good at getting a "no" to "give me more memory"
I suspect that overcommiting is one of the reasons for this though. Many programmers in the Linux world have integrated that "malloc can't fail" and the only error handling they bother doing is calling abort() if malloc fails.
Of course the fact that C doesn't provide any sane way to implement error handling probably doesn't help.
I haven't toyed with that in a long time (probably about a decade really) but back when I did it was still very difficult to get the OOM to behave the way you wanted. IIRC the scoring is fairly complex and take child processes into account so while it's technically completely deterministic it can still be fairly tricky to anticipate how it's going to work out in practice. And I did know about `oom_adjust`. Often it worked. Sometimes it didn't. Sometimes it would work too well and not kill a process that was clearly using an abnormal amount of memory. Finding the right `oom_adjust` is an art more than a science.
Overall I ended up in the camp "you shouldn't throw passengers out of the plane"[1]. The best way to have the OOM killer behave well is not to have it run at all. If I don't have enough RAM just panic and let me figure out what needs to be done.
Because it doesn't have a 100% success rate doesn't mean it shouldn't be considered, otherwise we could use the same logic to dismiss basically any rule, law or regulation ever made.
Echo chambers are never a good thing, echo chambers built around hateful extremist ideologies are a lot worse. By forcing these people to get out of them some good can be achieved. Of course some of them will manage to regroup elsewhere but statistically a significant proportion will return to a more healthy lifestyle.
The problem with extremists is that they drive people who disagree with them away. I've been a fairly heavy user of 4chan for well over a decade now, and I even spent some time on 8chan. I like the anarchic, less ego-driven nature of anonymous image boards. You avoid most of the empty posturing from other social networks.
I even think that 8chan was a great idea on paper. It's basically 4chan with Reddit's ability to create sub-communities on a whim instead of having to beg the admins to create a new board. I created a few of those myself.
But then of course the fascists took over. Admittedly on 8chan is happened almost immediately but on 4chan it was more gradual. Now 8chan is (rightfully IMO) dead and frankly I wouldn't be too sad to see 4chan, or at least some of its more popular boards, go the same way. The /pol/ cancer spreads everywhere, the big boards are 50% shitposting and 50% hate speech. And not in a fun "let's make ironic memes about Hitler to push people's buttons" way but in a rather depressing "I seriously hate women and minorities" way.
The more moderate people gets driven away. Actually any sane people would be driven away from this terrible and constant negativity and all you have left are the zealots who feed on each other's extremism. It's not free speech, it's a circular feedback-loop of radicalization. I've genuinely read a (supposedly videogame related) thread yesterday on 4chan where somebody was trying somewhat successfully to appear moderate by saying "I support white nationalists but I don't think we should be killing brown people". How nice.
Note that Reddit isn't a whole lot better at handling this, they're just better at hiding it under the rug while posturing in their PR releases.
I don't think the parent was talking about this specific type of attacks but other types of hardware backdoors. I think the answer to that is very obviously yes, and given what we know about intelligence agencies I'm even willing to go as far as saying that it is likely (or at least, if you have reasons to be worried about Uncle Sam getting to your stuff you should consider it a very real possibility).
Modern ASICs are so complex that I'm sure that sneaking a tiny backdoor into the behemoth that's a modern CPU or embedded SoC would be almost trivial. They'd also have great plausible deniability in case they're found, if something like SPECTRE was an intentional backdoor how would you ever prove it for instance?
If I could easily upload my code to this smart bulb and leverage it either for creative or practical endeavors then I wouldn't necessarily consider it wasted potential.
But here you have this bloated tech that you can't even easily leverage to your advantage.
I do agree with the general point that the progress we've made over the past few decades is mind blowing, and we shouldn't forget how lucky we are to experience it first hand. We're at a key moment of the evolution of humankind, for better or worse.