Checking just now I see that comments up to 3 - 4 years old have been restored.

I'm not going to speculate as to why (beyond agreeing it's more likely to be incompetence than malice) but in my case at least there are definitely long deleted comments that have been restored.

Unless the objective isn't to deescalate.

If there's no due process, reddit doesn't deserve to be held innocent.

Oh, the sleighthanded irony.

Same guy who un-personed Aaron Swartz, claiming he wasn't a cofounder after Swartz died, and removing him from Reddit's founder page.

I think it makes sense for anyone who values objective truth above any other agenda. "Benefit of the doubt" is just acknowledging that we don't know for sure.

Maybe not individually, but this is an IPO and the P stands for Public, and when you aggregate everyone together then intelligence is a moot concept.

Have you heard the recent popular saying that Googling things barely even works anymore unless you append reddit to the query, which tends to bring up actual information instead of SEO trash?

It's what normal people did before the internet.

People who didn't were known as lynch mobs, and were considered bad.

Thanks to the web, it's now perfectly normal to believe the worst of people for no better reason than to fuel one's own anger issues.

I believe that in this case it's more that Reddit's management has completely lost any sort of trust, it's not so much to fuel one's own anger issues but give the current context there's very little in terms of Reddit's management being trustworthy, transparent. Spez was caught lying in the open, how can one still have any trust they aren't lying in other aspects?

Let's agree that this particular case is not a baseless witch hunt, Reddit's management own dishonest actions have brought a dissatisfied lynching mob to them.

I do seem to recall that their database schema is mostly a big unstructured key-value table, so it's possible that this is part of the explanation - and they've never cleaned up any garbage/orphans in at least 3 years?

Meh. You're not exactly wrong but I think it's pretty common for user-generated content sites to follow a logical delete strategy. It holds open the door to being able to restore data deleted by end-user error, and within the bounds of their data retention policy keeps data around that may be useful for internal analysis.

Actually come to think of it seems plausible that they only have ~3 years of logically deleted data, having purged deleted records older than that.

It's also plausible they had all the is-logically-deleted information in some redis datastore that wasn't being reliably persisted to disk and the process had to be restarted for the first time 3 years.

I'm actually leaving my restored comments untouched for now out of curiosity about what they'll do about it now that the issue is known. I think that will probably answer the question about whether this was accidental or intentional.

I wouldn't put it past Reddit to restore old comments given sufficient motivation, I just have a hard time imaging how the cost/benefit analysis would say that this is a good idea at this specific point in time.

It seems plausible that with all the other churn going on at Reddit - and as others have noted a large number of people deleting comments and accounts and maybe subs - that they accidentally restored some data-store to the wrong snapshot or something.

I just don't understand how the difference between "we HAVE N million comments" and "N million comments HAVE BEEN posted" in some investment deck could be worth the risk to reputation and good will, not to mention potential GDPR violations or bad press from doxing stalking victims or whatever.

Someone else mentioned SEO as a possible motivation. I might buy that. If Reddit is losing PV and DAU and restoring a bunch of old content would offset some of that with organic search traffic, that seems like something they might do.

For most users this isn't going to be a problem but my guess is there is a rather big chance for a number of the comments that were restored there were really good reason why they were deleted and now Reddit are responsible for them being online again.

how did you check? profile page?

In other words, when the WARN act applies I don't think it's sufficient to give 90 days of severance. Those employees must remain on the payroll during the notice period.

I think it's common to tell these laid-off employees "you're on the payroll but not expected to report to work during the next 90 days", so it's kinda a distinction without a difference, but it does or at least could have an impact on things like benefits, bonus payouts and vesting.

This means that you can give the full notice and no severance whatsoever. Alternatively, you can give no notice but a minimum of 60 days worth of pay.

Curiously, based on the DOL guide at [1], which to be fair isn't text of the actual law but it is an official government publication meant to explain it, _technically_ it is _not_ acceptable to give 60 days of severance in lieu of notice, but since the penalty for violating the act is a 60 days pay and benefits to all impacted employees, it works out the same either way.

> Can I pay my workers their salary and benefits for 60 days in lieu of notice? > > Neither the Act nor the regulations recognize the concept of pay in lieu of notice. WARN requires notice, making no provision for any alternative. Failure to give notice does a significant disservice to workers and under-mines other services that are part of the purpose of the WARN Act. However, since WARN provides that the maximum employer liability for damages, including back pay and benefits, is for the period of violation up to 60 days, providing your employees with full pay and benefits for the 60-day period effectively precludes any relief

[1] https://www.dol.gov/sites/dolgov/files/ETA/Layoff/pdfs/_Empl...

This is not a lot cheaper than what you quoted, but for ~$2k/mo you can rent a 1 BR apartment in one of those relatively new, relatively fancy condominium-style medium-rise buildings at Reston Town Center (essentially the "downtown" area, or at least one of them) which puts you in very short walking distance of a bunch of tech offices and even a good number of nightlife and entertainment options. You could easily live the "15-minute city" life there. It would be a little bit like living in a large outdoor mall, but it's a very walkable "neighborhood". (EDIT: the DC metro system is also within walking distance.)

There are a handful of other "tech hubs" like that scattered around the DMV.

It may not be feasible in all cases, but it's definitely feasible in some cases, and it absolutely works.

In particular, bike commuting is an excellent way to integrate exercise into your daily routine without going to the gym or the tedious exercise-for-it's-own-sake activity. It's not practical for everyone, but between power-assisted e-bikes and the observation that you don't need to do it _every_ day, it's a lot more achievable than many think.

Similarly, if you take public transport to work (or elsewhere) you could get off a stop or two early and walk the rest of the way to get some of the benefits even if lacking the time or stamina to do the whole trip on foot.

Integrating exercise into some task or activity you were going to do anyway (e.g., commuting or running nearby errands, if applicable) is much easier than trying to maintain discipline and motivation to exercise as a dedicated, stand-alone activity.

Surely somewhere in that more-than-half-of-all-car-trips there are a few examples of car errands that could be easily replaced by bike, scooter or foot.

EDIT: incidentally even in the most car-centric dystopian suburb there are ways to incorporate more walking into your routine. The next time you go to a strip-mall or big box store you could park on the far side of the lot and walk to the door. A minor inconvenience in both time and effort, but you could probably add 1/2 mile or more of walking to your Saturday afternoon errands that way.

But I stand by the statement that most able-bodied Americans could find some way to incorporate more human-powered transport into their routine if they really wanted to. And in many cases they could do it without any adding any superfluous travel. I.e., it may be slower or even less convenient in some way, but it was a trip you were going to make anyway. You're just changing the mode of transit.

(Incidentally if it's truly too dangerous or inconvenient to walk across the Costco parking lot with a loaded shopping cart I think we're well on our way to the people from Wall-E.)

Like yeah, they maybe can't, are you disabled? No? Well then.

It is nevertheless eminently possible to walk and bike more.

Except just as you noted the conventions change across platforms, contexts and over time, so they aren't really uniform at all.

If you're moving between Windows, macOS, and Linux, or between GUI, command line and remote shell (either within or across any of these) you're already context switching on a regular basis. And if you stick around long enough an OS upgrade will come along that moves the window controls and menu buttons around so you need to retrain your muscle memory (and update your end-user documentation).

If anything some of the long-established, old-school conventions are probably _more_ uniform and consistent. E.g. in vi/vim `:w` will save and `:n` will jump to line n - always and everywhere. In a terminal `find . -name foo` will search the filesystem - (almost) always and everywhere.

That sort of thing isn't comprehensive (i.e. it doesn't cover action you'll need to take) but it's kinda nice when it's available. Maybe we'd be better off if select-then-middle-click worked for copy/paste everywhere.

Moreover it is supported out-of-the-box in emacs: `M-x list-packages`.

I think `:packadd` or something may be the equivalent for vim.

Or just use the menu; click on "Options” → “Manage Emacs Packages”. No need to scare people with “M-x” weirdness right out of the gate when it isn’t necessary since the option is right there in the menu.

But seriously you raise a good point. The OS-native menus in aquaemacs and similar go a long way toward making emacs more accessible and explore-able.

No joke, it is legitimately hard for a newbie to figure out how to close emacs, which is pretty ridiculous. (It's `C-x C-c` btw, but I honestly don't know how a first-time user could figure that out on their own without a menu. You need to be _told_. It's absolutely crazy that you need to consult the manual to know how it exit the program.)

EDIT: It looks like this thread is too deep for me to post a genuine reply, but just to respond to the "it's just plain emacs too" comment. Good point, and I was aware of that but I didn't know what to call the plain-vanilla Windowed/GUI-enabled emacs. I guess it's just "emacs". I actually hesitated on naming aquaemacs for exactly this reason, which is why I hedged with "or similiar".

FWIW you _can_ get emacs to launch as quickly as, say, vi, and to respond to input as quickly as just typing in the terminal (but in my experience the default GUI doesn't have noticeable input latency):

* `emacs -nw` will launch emacs in a terminal rather than a OS-native GUI window. This has surprisingly little impact on the interface or usability, but it does make cosmetic tweaks like font-rendering more difficult.

* `emacs --daemon` will start an "emacs server" process running in the background, and `emacsclient` will connect a UI instance to it (so you don't need to re-process all your .emacs stuff each time)

That said you can probably introduce a lot of input latency by hooking a slow method to the keypress event, but that applies to Atom and VSCode as well as emacs. But all three of them seem to do OK suggesting auto-completions of one kind or another, which must be handled on keydown or similar, so maybe that's not as critical as I assume.

I usually have a text editor open all the time anyway (recently Atom, lately VSCode) so the time-to-launch isn't that big of a deal in practice (and isn't _that_ large to begin with) but I am disproportionately, irrationally annoyed every time I need to wait for the editor to start.

But VSCode is also less responsive, more resource heavy and ultimately less flexible or extensible. Vim and emacs have more of a learning curve, and their configuration is more fiddly, but the biggest hurdle is probably that the interfaces they use for this predate modern GUI conventions. Notably the "search by keyword, click install, done" workflow for adding extensions is definitely standard behavior in emacs (and vim too, I assume).

Configuration fiddling aside - and that shouldn't be a daily activity - "Vim and Emacs cannot compare to VSCode when it comes to productivity" is a claim that does not hold up to scrutiny. In the hands of an expert user, emacs (and again, I assume vim too) is definitely more capable and productive than VSCode. I'm fairly confident this could be demonstrated objectively. They just _do more_ and can be made to do it _exactly the way you want_ them to. The learning curve for vi/vim and emacs represents an investment, but one that can pay off handsomely.

The topic of this thread is actually a perfect example of one of the major advantages of these "classic" editors. Atom - and countless editors that have come before - has been sunset. And it will eventually happen to VSCode too. Your Atom customization skills (and mine) are wasted. Now we need to pick up a new editor and climb a new learning curve. But vim or emacs mastery is a skill you'll literally be able to use for the rest of your career.

It's absolutely valid to decide that learning how to use these esoteric tools well is not worth the effort to you personally, but there _is_ a reason these tools have been around for nearly half a century.

Assuming developers avoid resource leaks (and to be fair some notable Electron-based apps tend to be both leaky and long-running) the main drawback of Electron seems to be the non-native look-and-feel. But that _could_ be worked around (for the most part) with some effort, and I suspect most users don't actually care that much. The web browser is still probably the most-used desktop app. The web look-and-feel is familiar and intuitive to users, even if it stands out a little from the UI of native apps.

Poor resource management aside, something like Electron is probably good _enough_ for most applications.

I have nothing intrinsic against electron, and I'll take everything back if I see these "natural fits" actually fit.

Contribute more to e-waste! Pollute more! Consume! Consume!

A bog-standard 8-year old computer would be considered a supercomputer by the standards of the '80s, so at some point we ought to put some effort into making computers feel like the insanely powerful beasts they are. And Electron won't help with that.

Most people in this world would rather spend the required 400usd needed to get a >=8GB computer on fixing their vehicule/home and pay their monthly bills.

This +environment damage limitations.

Apart from the software and system engineers I don't know a single person in my social circle that own a computer with more than 4GB of memory. And I am not living in a third world country.

That's the problem though: it won't. There is no modern system on which Electron apps run without being irritatingly slow.

On the other hand, vim or Emacs with all features I personally currently use in vscode come in at a fraction of the memory usage, and it is a bit dumb to have to use that much ram for slack or discord considering how light IRC clients used to be.

VS Code is unusable on my laptop. I tried it, it's way too slow to be usable. I've used vim with a few plugins that got it to the same feature set as VS Code and it's actually usable. At some point I tried Lite XL, and it was incredibly fast with the same features. More recently, I tried helix and I can say that I've never used such a fast editor with auto complete and all that.

Most electron applications waste me time and energy (both human and electricity), and if software keeps going this way it'll start wasting me money. I'm not thrilled, but like you said, what are you gonna do?

As a baseline, Electron performance _should_ be no worse than a regular SPA-style web UI running in the browser. Unless you find _everything_ on the web "irritatingly slow" it's surely _possible_ to create an Electron app with acceptable performance.

From my perspective anyway, I've both used and contributed to multiple Electron-based apps with performance that was not only "adequate" but not noticeably different from a typical native app. Basic Electron apps (done correctly) will look and feel more or less like a web app but perform more or less like a web app too.

FWIW there is a lightly-curated list of electron apps at https://www.electronjs.org/apps

I'm not sure offhand which of those is a good example of UI/UX and performance, but if you poke around with some of the medium-scope stuff (not too basic, not too ambitious) I'll bet you can find some examples.

UPDATE: I spot checked a few of those Electron apps for the fun of it. Here are a few examples you may find compelling:

* Deer - https://github.com/abahmed/Deer/releases/tag/v1.0.0 - A simple styled-text note-taking app that was last updated ~4 years ago. I don't _love_ all the UX choices personally but the performance seemed reasonable in my short test, especially considering the version of Electron they are using is 16 major releases out of date. There are probably more robust note-taking examples in that list (e.g. Inkdrop, Notable, Notion), this just happens to be the one I grabbed.

* Pencil - https://pencil.evolus.vn/ - A much more complex app for drawing fairly sophisticated Visio-like diagrams and UI mock-ups. Performance wise it seems about as responsive as a typical native app on my nearly 3 year old MacBook. But it may have large-ish baseline memory footprint so YMMV.

* I notice that some well known apps (or at least brands) are listed, like Trello, Asana, Notion, GitHub Desktop, Basecamp, WordPress, Twitch, Skype, Signal, Quickbooks, Light Table, Figma, WhatsApp, etc. For several of those I for one was not aware that they were Electron-based, and I'm guessing at least some (but probably not all) of those work pretty well. I think I've used both GitHub Desktop and Notion without anything to complain about but I'm not surprised that they are Electron apps. I've definitely used that Skype client and never noticed that it was an Electron app. I've never used it, but I'd bet Trello works well too.

IMO I think this demonstrates my original point in this thread: When an Electron app is well-engineered you don't even notice that it's Electron. It's survivor bias. People think Electron apps are bad because it's the bad apps that are noticeably Electron-based.

That said, the ratio of fast electron apps over slow electron apps is much worse than the one of fast native apps over slow native apps. If it's not the tech then it's the people around it. Either way, if I hear "hot new program" and it's electron, I don't think I'm in the wrong to assume it will also be rather slow.

At the end of the day, all I really care about is for the programs I use to work well and reliably. I don't really care how you make them, and as I said I don't have anything intrinsic against electron.

You're at least the 3rd person I've seen make that observation in this thread. I don't get how VS Code made this so hard, isn't it fundamentally built on a fork of Atom's core? The CSS and JS customization seemed more capable and accessible in Atom somehow.

I've heard only good things about the Sublime Text UX for literally a decade or more, but is it "hackable" in the way that Atom and VS Code are? Emacs-like hack-ability with less esoteric scripting (and a better UX out-of-the-box) is exactly what attracted me to Atom in the first place.

That means that in VS Code actions like "right click to open context menu" or "type in Command Palette to filter commands" are instantaneous regardless of your extensions, as no extension code gets run. But extensions can't change the layout of the editor, or really do anything not exposed by the API.

If you want hack-ability there is an extension - https://marketplace.visualstudio.com/items?itemName=betterth...

The vast majority of the UI uses a custom GUI toolkit and doesn't have any API, though you can theme it. There's a few things that are extensible in limited ways: the command palette, text phantoms, input boxes, html sheets, etc. So no it's not generally hackable.

No. AFAIK the only thing common to them is Electron.