notalaser

> Well this justifies MS's decision for forced updates in Win10. Not that I like it, just saying.

Unfortunately, I think the active hours period cannot be set to more than twelve hours, which is less than the time required for some surgical interventions. I can almost imagine it: OK everyone, ten-minute break while Windows installs its updates, this guy who's been on life support for the last ten hours can wait a little longer.

That's why updates are not forced on business-grade installs, and forcing them would be a very, very stupid decision.

Forced updates make sense for home users, since Microsoft can't depend on someone requiring them to keep their networks secure. For other types of users, second-guessing update policies is always a bad idea.

> You can get the best experience using the most up-to-date APIs available on your platform or the most compatible, lowest common denominator experience, but you can't get both.

Thank God the guys who write the kernel never thought about this :-)

Besides, this isn't what I was criticizing. What I wrote (it often helps to read the whole argument before offering a counterpoint) is:

> Both major projects (Gnome and KDE) are increasingly depending on Linux-specific technologies (mainly through systemd dependencies, e.g. timedated, localed, hostnamed and logind, which are explicitly Linux-specific). They can be replaced by shims, fortunately, but these are difficult to write, because the components that they replace move quickly, often not very transparently, and without much documentation.

Windows, MacOS and (at least Open)BSD don't get all this hate because they tend to introduce components when they're reasonably stable and almost always with full, proper documentation. They rarely dump beta-quality code for the community to test and document, like Red Hat did with pretty much every desktop technology they developed after 2005 or so.

I've used Linux since back when there was no "Enterprise" in Red Hat Linux :-).

The driver situation has massively improved, absolutely. The second time I installed Linux (on a brand new computer) was scariest -- S-ATA was super cool and new and my S-ATA controller wasn't supported, so I had to build a patched kernel on my old machine and boot with it...

But higher-up, I don't think we've progressed significantly past where we were in 2010. Sound still breaks (and ironically enough, it had just started breaking, with Alsa finally getting proper soft mixing and hotplug support via udev), KDE and GTK applications can no longer get uniform themes, display managers still get laughable bugs...

> Could you expand on some ways that linux desktops are getting worse/less portable?

Less portable: both major projects (Gnome and KDE) are increasingly depending on Linux-specific technologies (mainly through systemd dependencies, e.g. timedated, localed, hostnamed and logind, which are explicitly Linux-specific). They can be replaced by shims, fortunately, but these are difficult to write, because the components that they replace move quickly, often not very transparently, and without much documentation.

Worse: frankly, what I dislike most is the frequent rewrites of major components, which keeps everything in a perpetual almost-stable state. I can get my Plasma box to act up just by trying several window decorations one after another in System Settings.

But there are a lot of things that recent Linux converts don't realize about their major pain points. For instance, until a few years ago, getting uniform looks between GTK, KDE and Qt applications was largely a solved problem, thanks to e.g. projects like QtCurve (there were several other solutions, QtCurve was just the one I liked most). Good luck with that today (see e.g. https://github.com/QtCurve/qtcurve-gtk3)

Basically, except for Bluetooth and proprietary graphics driver, there's nothing that "almost works" today which didn't "almost work" ten years ago, either, except it probably got rewritten at least once.

> Also what is IVI? this: https://www.ni.com/ivi/what.htm ?

Nope, it's short for In-Vehicle Infotainment systems. It's one of the very lucrative markets for Linux solutions, because the competing solutions are either tied to a specific big player's interest (Android) or super expensive (QNX). Video entertainment in general (IVI, smart TVs etc.) is the main force that drives graphics and UI-related development in Linux.

It's not a bad thing (quite the opposite, I certainly don't miss using VESA drivers...). But it does mean that, for the people doing work on major components of the graphics infrastructure, desktops aren't a priority. It needs real community effort in order to be turned into a viable desktop option, and that's pretty hard considering the rate at which developers are being driven away.

> I recoil at the possibility that some developer 5 years from now might ask me "Why bother installing your own linux distribution? You can just get Windows Go 15 and run Arch/Ubuntu/SUSE from inside there. Don't forget to disable the ads and tracking that come standard".

"I mean, the privacy is shit, but you can sort of deal with it. But at least you don't have to dance the Ritual Dance of PulseAudio if you need to do MIDI (or get as much as a hiss out of your speakers), suspending your computer doesn't garble your desktop background or desktop icon labels, you can update Windows Go 16 and it'll work after you reboot..."

I don't like Microsoft any more than I like any company of its size, but they're making a compelling case, while the Linux "community" is busy supporting cloud, IVI, and IoT vaporware.

Edit: ten years ago I was certain they were going to pry Debian and OpenBSD from my cold, dead hands. But Windows, for all its privacy compromises, is working better and better, whereas Linux desktops are getting worse (and less portable), with a never-fulfilling promise that it's going to get a lot better when they finally get stable, this massive rewrite that we started like six years ago is just about done...

Edit edit: I know my comment looks overly negative and I seem grumpy but really, I'm not, I like Linux, I make a living out of writing Linux software and I've used it one way or another for almost twenty years. That being said:

1. Please stop recommending me that I use something more user friendly, like Mint or Ubuntu. "You can update to Windows Go 16 and it'll work after you reboot" was a joke about Ubuntu.

2. This "I got this new machine and it works flawlessly out of the box, Linux is great if you get good hardware" is the wrong mentality if you're not Apple. Every operating system, including TempleOS, runs flawlessly out of the box on some hardware. It's getting it to run flawlessly on hardware other than the developers' machines that's complicated. Go ahead, grab ten high-end laptops at random and see how well plugging and unplugging your monitor works, even on systems that are officially supported. How do you think I ended up knowing xrandr's command line options better than I know tar's?

Not being able to care for my Linux box is not my problem, my problem is that I don't want to care for my Linux box. I babysit Linux at least eight hours a day at work. I don't want to have to do it at home, too.

As soon as Canonical blows something off in Ubuntu, users can switch to whatever other Linux distribution they like (or remove/replace the misbehaving component, like it happened with the Amazon thing or early-ish versions of Unity). Apple users can't very easily switch to a better version of macOS (especially when they need to migrate their data out of the walled garden it's hosted in).

For #1, maybe company-mode can be of assistance? I haven't used it with Java (I never had to write enough of it to need Emacs), but I imagine it works.

The remote computer is often good enough to run an application but way too slow to productively compile a large codebase on it. Besides, you don't need to maintain two development setups at once.

This is a niche situation only because Microsoft's tools make it a niche situation. It's pretty much how all embedded software on this planet is developed (except that the network is replaced by a serial connection on the lower end of the performance spectrum, of course). In nix world, it's a super-common situation; e.g. at $work, where I write software for networking equipment, no one seriously expects that I'm going to compile stuff on the routers that ends up running that software. Most of them are capable of the required heavy lifting (they have CPUs in the same performance class as a pretty beefy desktop), but why?

You can run it on a remote computer (or a VM) and debug it from an OS X front-end that connects to the remote-running debugger over the network. It's a pretty common technique, gdb has had it for, what, fiftenn? Twenty years?

Maintaining two separate development environments, on two operating systems that you have to boot into separately is very annoying. Developing for an operating system other than the one you're running is about as old as the personal computer, I think :).

I've seen it done (on a large-ish codebase), using Perl as a preprocessor for C. It looked good on paper and we were really enthusiastic when we came up with the idea, but it quickly degenerated into the proverbial ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

In retrospect, we could have done worse, like use C++ :-).

There's also the best kind of hurt: outdated, insecure firmware that gets delivered to users who aren't aware of it, can't inspect it anyway, and even if they could, they can't do anything about it because the firmware is signed and you can't load your own.

This particular type of hurt is why I like GPLv3.

My path has been pretty much opposite: a long time ago, I was a big fan of BSD-flavored freedom and thought that commercial adoption of open technology was the best thing that could happen. After years of eating my own dogfood and seeing open code used solely as free work, with no regard to user or developer freedom, I'm not so convinced.

Frankly, I was cynically happy when a lot of GNU projects were licensed under GPLv3, and suddenly everyone who locks down their firmware (which is usually a big hunk of GPL code + a piece of shit web UI) was sent scrambling for alternatives and, gasp, even having to -- hear this! -- pay for the software that they proceed to resell. Outrageous. It also fueled the development of really good alternatives. It did make my life more difficult, but I'm satisfied that it also made life more difficult for companies that lock down their users and whose business model is largely planned obsolescence + no privacy.

(Note that this is heavily skewed towards embedded systems :-) )

One thing I still considerably like about BSD-type licenses is that they do not incentivize "community leadership and involvement" and half-baked upstream contributions for the sake of companies being seen as "thought-leaders" in their respective "communities". It does mean less upstream support for a lot of things (most visibly drivers), but it also means that crap in-house hacks stay in-house rather than being "contributed back" to communities whose users don't really want them, but don't really have a choice now that the community leaders are largely corporations engaging in free software circlejerking. This involvement for marketing's sake is a big part of why using a Linux system is so painful nowadays, six or seven years after it no longer needed to be so painful.

You can use the owner extension: https://www.frozentux.net/iptables-tutorial/iptables-tutoria... , which can filter based on the PID of the process which created the packets.

But what we generally do is, you know, not run plugins that phone home :).

Edit: I just looked on a Linux machine - things have changed a little. That used to be my go-to document for iptables, which is why I referred you to it. You probably want to consult something more up-to-date.

In any case: iptables can do filtering based on who created the packets.

Even later edit: it probably goes without saying, but just in case -- this solves only half the problem, because it can only identify the process based on its PID. This makes it pretty trivial to overcome PID-based rules. The usual solution, of course, was to filter based on UID and run the program under a separate account.

I don't know if this got solved in the meantime, I haven't used iptables in a while now.

The bummer for the companies doing the home routers is really just that it costs money. The only people who give a flying fsck about the F part are hobbyists, sadly.

Source: worked in this industry.

First, at the risk of pissing off fellow emacs-ers -- if you're already a regular Vim user, why not stick to it? It's a great editor, and I know a lot of people who use it and are just as productive as I am with emacs. Plus, if anyone ever needs to use their computer, you won't get weird looks when you tell them Caps Lock is Control on your keyboard...

Anyway, if you absolutely want to learn something else, I'd suggest going the other way 'round, really: start with something minimal and work your way up from there.

For the first 1-2 years, I think, I've used Emacs as little more than a glorified Notepad clone (in fact, I even used it with cua-mode). I think my .emacs file was barely ten lines long. I was transitioning to Emacs from nedit, an old-ish Unix editor with a Motif UI that was getting increasingly difficult to digest and kept crashing and had trouble with Unicode and man I'm old... anyway, all I really needed it to do was let me write text and paint it in pretty colors sometimes.

I then sort of picked up its features one by one, as I needed them. The keybindings came first, because it was weird the arrow keys for motion and the other keys for everything else. Then I got a larger monitor and I could fit more than two windows on it and I installed window-mode so that I could switch between windows with M-1, M-2 and so on.

(Please remember this was 2005 or 2006 or something, a 21" CRT was a big deal for me...)

That's pretty much how I picked up everything else: first big C project was how I picked up xrefactory, then xcscope. First time I had to do big merges was how I picked up ediff, and so on.

The best thing about having something as scriptable and customizable as emacs is being able to make it work exactly the way you want it. Making it work exactly the way someone else wants it sort of defeats the purpose, I mean, any editor already works the way someone else wants it.

Edit: ah, yes, to address some of your pain points:

- Remote editing: look into something called tramp-mode. It's not perfect, and I, for one, use it sparingly, but it may fit your use case.

- Weird key combinations: I'm not sure what to say other than "you get used to them". It may be worth looking into how i3 deals with this stuff, too. I no longer use a tiling WM, but when I used ratpoison, it fit near Emacs pretty well -- I bound C-t to Ratpoison's prefix key, and just didn't use C-t for anything in Emacs. But then again, Ratpoison (and its successort, scrotwm) were both written by Emacs enthusiasts, and used similar key sequences.

If you're curious about anything else, ask away :-)

> The best startups are ones that solve a pain point you yourself have experienced.

Aww, yisss. Case in point, EDA and, in particular, hardware description languages and tools. Every discussion I've had with someone trying to get into this has been so cringe-worthy that I'm actively avoiding now. Every self-professed hardware hacker thinks they have the solution that's going to end all this painful Verilog kerfuffle and yet they're so, so far from getting it.

Like the folks who thing the biggest problem with Verilog and VHDL is that they're so alien that it's hard to get software developers productive with them. Lack of electronics knowledge is what prevents most software developers from being productive in Verilog. A "better" language won't help. Paying attention in their Electronics or Systems classes is going to be ten times more helpful than a Scala/Haskell/whatever-is-fashionable hardware description language.

Or the people who think that development tools are what's holding FPGAs back and that FPGAs would be everywhere, were it not for how hard it is to program them. Trying to explain them that FPGAs are pretty slow gets impossibly difficult as soon as the words "Intel" and "softcore" are mentioned.

Not that there aren't a lot of things to improve in FPGA development tools, or in hardware description languages (which is why you see so much work being done on increasingly higher-level synthesis tools). But unless the number of millions of dollars you're willing to invest is not at least half the number of years you've been studying high-speed IC design, chances are you're as far removed from having a serious answer to all these problems as you are removed from being a modest person.

/rant

> I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions.

Mathematical facts are a very human invention, just like the transistor. I picked calculus precisely because intuition based on physical observation gives the wrong answer nine times out of ten.

> assuming everyone is a robot who's memorised all corner cases of their tools

But this is not a corner case! I'm not talking about an obscure quirk (God knows how many C has!), this is literally syntax, the first thing you learn about a language!

And then people wonder why other engineers smirk when they hear the term "software engineering" :-).

We're not all fitted with the same Umbrella IntuCard Mk. II Intuition card so that, relying on intuition alone, we can all reach the same results from the same inputs. Relying on intuition to figure out how a language works is about as smart as relying on intuition to figure out the limit of a series, how a telephone work or how a transistor works -- all three of which have been definitely designed for humans to use, since there were nothing but humans who could use them back when they were invented.

I don't like it any more than you do, and my life would be much easier (and probably happier) if it weren't like this, but blaming it on the language is the equivalent of the turtle blaming calculus after losing the race to Achiles.

One could equally point out that programmers should form mental models by reading documentation, rather than relying on intuition. It's not like you have to dig through compiler sources to find out that sizeof is an operator. Even if it wasn't plainly documented in pretty much any properly-written material on the C programming language, it's pretty obvious that sizeof can't be a function, since a function doesn't have access to the sort of data required in order to retrieve this sort of information.

...or are more likely to be doing the kind of work where no one is pestering you about when to come at work and when to leave.

> What do people do when they feel they are burnout?

Take more than a free Friday.

The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).

> A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience.

Holy fuck, can you imagine the supercomputers that were required to display Geocities websites in the 1990s?

Pretty much this. A few years ago, I used to work for a small-ish American company that had offices in my corner of the world in Europe. They tried to pull this sort of crap in our office -- everyone except the guy in charge of the local office (who was a VP of something something -- his company had been bought some time before) quit within months.

The occasional week-long sprint before a release is one thing. I think better management/planning would avoid them, but they're normal in such a competitive industry, I guess. So I've worked 80-hour weeks at times, no complaint here. In fact, I think they're healthy now and then, I like the buzz that I get at 3 AM, it's good concentration exercise...

Constant work at this pace though, no, can't do. First, that's how bad software gets written. You literally get worse at your business for doing it. Second, those additional hours per day aren't just family time hours. They're also learning-new-things hours, reading hours, keeping myself informed hours, debating stuff with friends hours and so on. Not having them further decreases my chances of getting better employment somewhere else (or even getting a better position where I work right now) and slowly turns me into a social retard living in a bubble made out only of headlines. That can't be good for me.

Oh, and without additional pay, it's illegal pretty much everywhere around here.

It's probably like getting drunk -- getting shitfaced once a year with your old highschool friends to celebrate the anniversary of when you all got arrested for egging the principal's house is kind of a healthy social activity. Chugging a bottle of Jameson every day because that's how we do things around here is called being an alcoholic and it's really bad for your insides.

I've had colleagues who glorified this sort of work. It does create some amount of peer pressure (unsurprisingly, the managers are quick to praise this sort of stuff), but after the ripe age of 17 I've learned to deal with that.

Back when Solaris 7 was a thing, dependency hell was very much a thing.

The GPL an unpleasant side-effect: it encourages companies to pay lip service to community involvement and to be seen as "community leaders".

If you go to any major conference now, you can't have a beer in peace without someone from one of these super-open companies trying to tell you how super-excited they are to drive innovation as part of a thriving community or whatever other cliche is popular nowadays. In the meantime, though...

Most companies that don't give a shit about community and openness can keep their BSD code tucked away. For most companies that try to make money out of GPL software, not giving a shit about community and openness is usually a bad PR move, so there's a great incentive for pushing as much of what you do as far upstream as possible.

You'd think really bad patches would get rejected (and more often than not I guess they do), but in many cases, the project leader(s) work for the same company as the guys sending the shitty pages, and of course they get integrated, because $company $qualifier Linux $latest_version + 1 needs to ship this June and the feature has already been announced. Whole projects, or at least major modules/sub-project, are effectively a one-company show or an internal playground.

This isn't bad because companies are scary, it's bad because, while the code is out in the open, the agenda and the planning processes aren't, and it fractures the community a lot. It's a good part of how projects like PulseAudio and systemd ended up with a bad name: everyone can agree that they at least offer some useful features (some people would go as far as to say they're "much-needed improvements", but that's far more debatable than whether per-application volume setting is useful), but they were pushed way, way before they were ready for production, and everyone saw this as Red Hat's attempt to enroll everyone into their beta testing program.

In many other cases, commercial involvement in GPL projects is pretty much of no value. They publish the changes because they're required to, but most of the code is so brain-damaged it can't be used upstream, or is just a GPL-licensed interface over a proprietary library, a la nVidia. I'm guilty of having written both types of code, on several occasions, so it's not like I'm really just a BSD user for whom the grapes are too sour.

There's also the fun crowd that's using outdated, unsupported stuff on their rootfs because the project switched to GPLv3 six years ago. They really, really like not having to pay money for 99% of the software on their device, but they really, really REALLY like making sure you can't flash their devices with your own firmware, so they can't do GPLv3. Of course, the old branch no longer gets bugfixes or security updates, so their flashy gadget will fall flat on its head as soon as it's exposed to an Internet, but that's ok, you'll buy a new one next year anyway.

20 years ago I was really, really happy when I heard that some company was licensing something under GPL, or contributing to a GPL project. Nowadays, frankly, I'm more scared than happy. There have been success stories, but they're getting fewer and fewer.

> One person involved with the Linux Foundation

...there are a lot of people involved with the Linux Foundation, what didn't help in this case is that the one person involved with the Linux Foundation who came up with this piece of Ballmer-era nostalgia is the Linux Foundation's Senior Director of Open Source Consulting.

It's a pretty major PR blunder. It rubs people the wrong way because it basically repeats the anti-Linux arguments which used to be promoted by a lot of companies that were heavily-invested in proprietary software -- some of which are Linux Foundation members today.

The terms aren't exactly innovative. 20 years ago or so they were used liberally (and, I think, coined) by a particularly disliked company from Redmond, and their marketing material (thinly-veiled as whitepapers, sometimes from partner companies) read pretty much like this guy's piece.

This is basically a blast from the past, except 20 years ago we'd see it on Microsoft's website under some Get the Facts stamp, not on the Linux Foundation's website.

> It's undefined behavior meaning, by definition, it's not C. It's not defined in C.

The C99 standard defines undefined behaviour as

"behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements"

Undefined constructs are not necessarily erroneous (and therefore, in a way, "not C"). Many of them are perfectly legal constructs for which the standard you're targeting simply imposes no specific requirements. In fact, C standard documents list several (as in, I think, hundreds of) examples, many of them perfectly correct in terms of syntax. The standard just doesn't dictate what the compiler should do with them.

If you really like playing the words game, you could, at best, claim that undefined behaviour isn't C99 or C89 or whatever your compiler is targeting at a specific time, but it's very much C.

> It's not defined in C. If I had an list of all definitions, would an undefined item be in my list? No.

And yet Annex J of the C99 standard has a list of undefined behaviours.

And that list itself is just a reference, because the C standard is otherwise full of cases where it does not dictate requirements -- effectively, you know, defining a bunch of undefined items. E.g. 6.2.4, 2 in C99, where object lifetimes are defined, states that "If an object is referred to outside of its lifetime, the behaviour is undefined".

Besides, come on, look at code like this:

int foo = INT_MAX;

foo++;

How exactly is this "not C"? Can you think of any perfectly standards-abiding compiler that will not compile this? Does it use any keywords, identifiers or grammar that a C compiler does not understand?

On the other hand, the people who use electron are generally people who should be using Qt.

The themes section is what I mourn the most. It was a great repository of computer art. And frankly, the content there was a lot more original, bold and and innovative than what you see on *-look.org today.