HN user

8456523

26 karma
Posts0
Comments25
View on HN
No posts found.

This drop is largely caused by deaths of despair, partly related to a lack of affordable health care in the US

I'm curious whether you believe lack of affordable health care in the US causes a lot of death from diseases of despair; and if so, why you believe that.

I always thought that health care is relatively ineffective at preventing death from those diseases -- addiction in particular, but also suicide. In other words, I always thought that the solution to this particular epidemic will require more than just allocating more money to health care.

Also I always thought that most of those dying from diseases of despair do not suffer from other chronic illness, e.g., diabetes, that health care is effective at treating. And I always thought that among those Americans without a pressing current need for health care, simply not having access to good affordable health care, although bad, is not bad enough on its own to drive a significant fraction to suicide or substance abuse. In other words, I always thought that the despair has another source, e.g., a lack of friends or a lack of feeling integrated into a community.

A 2 day standoff for a shoplifter seems like a huge waste of city resources and taxpayer dollars.

Correction: a 2-day standoff for a suspect who when chased by police, barricaded himself in someone else's home with a gun.

If that is how he acts when under observation by the police, what does he get up to when he thinks he is not being observed?

It was peak America mostly for straight, white, Protestant men.

It was not peak America for gay people. Or for blacks. Or for women.

It makes me sad how often discussion of any particular social question on this site gets derailed into a discussion of identity politics.

In 1950, Americans owned 75% of all the cars in the world. Surely, black Americans owned cars at a lower rate than white Americans did, but they probably owned cars at a higher rate than whites in Sweden, France or the UK did. The point is that there are major influences on prosperity that cannot be reduced to the same old identity-politics tropes.

Almost all modern jet engines have (ducted) fans. In planes that never go supersonic, e.g., all current commercial airliners, the fan provides most, but not all, the propulsion. And the only difference between a fan an a propeller is how many blades it has. (The presence of a duct around the fan does not change anything basic.)

But even if they did not have fans, there is no fundamental difference between using a propeller or fan to speed up the flow of air and heating the air inside a chamber to speed up the flow of air. (The fan is used because at subsonic speeds it can be made more efficient.)

In other words, all 3 means of propulsion work by conservation of momentum.

Canola oil looks good on paper, but there is something very unhealthful about it if my experience is any indication. (I have to eat well or my chronic illness gets worse almost right away.)

I avoid most seed oils, e.g., safflower, sunflower (regardless of how the seed oil is grown or refined) but canola is the single oil I take the most care to avoid. I use olive oil almost exclusively.

I don't have a decent theory about why it is particularly bad for me. Sorry I can't be more informative.

Aren't you worried that such a startup will run up against the same systemic biases that have been preventing poor minority neighborhoods from accessing healthy food at reasonable prices for decades?

In other words, food truck entrepreneurs have been around for decades, so why doesn't the service you imagine exist yet? Because so far no one with the right motivation, i.e., no one with their heart in the right place, has tried what you imagine?

Just because there are peer-reviewed scholarly articles making an argument does not make that argument correct.

I hope anyone who suspects they or someone they love has chronic lyme will dig deeper than just reading scholarly review articles. A professional scholar tends to write only about things that they anticipate will advance their career.

In particular, I hope anyone who suspects chronic lyme will meditate on some of the comments on HN written by people who claim to have recovered from chronic lyme or what they suspect was chronic lyme. If you search the web for information on chronic lyme you will encounter a lot of material by people who make a living trying to persuade various segments of the public in one direction or another. (Some of the professional persuaders have MD after their name.) On HN comments in contrast I am satisfied that almost all the substantive comments about chronic lyme are currently not written by professional persuaders.

That's not true.

It is difficult for humans to estimate how they spend their time, but my guess is that I've spent at least 35 hours recently exploring Windows 10: Changing various settings, installing software, asking Windows-specific questions of Google Search.

And I'm writing this on Windows. (Except for the Windows-specific questions, I'm not counting web use in the estimated 35 hours because of course the web mostly works the same way across the desktop OSes.)

I think computer users vary drastically in how much they value predictability in the software-based systems (or "environments") they use, and that I value predictability much more than the average user does.

I realize that it is unreasonable to hope never to be surprised at the response the system makes to an action of mine. But my response to being surprised is to try to understand how I could correctly predict similar responses in the future. For example, I might try to understand the reasoning of the designer of the part of the system in question. Or I might search for ways that I might have misinterpreted the situation. And I don't like it when I never reach an understanding of the surprising response.

Its source code's having half a million folders is a sign that Windows will never stop surprising me, which, all other things being equal, makes me less hopeful that spending time getting to know Windows will pay off for me.

Life of course will never stop surprising me. But to have any hope of getting anywhere in life or achieving any goal whatsoever, my brain must be sufficiently reliable and predictable. I see my computer as an extension of my brain that helps my brain be more reliable in the ways that will help me to succeed.

If you see your computer or the web site you are interacting with as a potential friend with agency of its own, then I can see where you might be offended by my original comment. I see computers and web sites as tools. Levers, if you will.

You can spend a year (seriously) just drilling down the source tree, more than a half million folders

I would be more inclined to switch to Windows if its source tree were smaller.

My guess is that a big reason I prefer MacOS over Windows is that Apple has been much more willing to drop support for legacy hardware and old applications to keep the source code more manageable.

My hope is that some enterprising developer will write an implementation of vscode's extensions API in Rust without the Chromium dependency and that that will lead to something with most of the functionality of vscode, but much less bloat.

It's on a different computer than the one I am using now, so it is going to take me at least a few hours to share it. I will make another reply to your comment when I have it.

Yes.

To be precise, after `(server-start)` is evalled inside the Emacs.app process, whenever the command line `emacsclient <file name>` runs anywhere, inside or outside the Emacs.app process, the Emacs.app "visits" (opens) <file name>.

Mouse and scroll-wheel integration roughly doesn't work at all.

emacs, when started with the -nw flag, has nothing to do with mouse gestures. The terminal emulator (iterm in your case) sits between you and emacs and does not pass mouse gestures to emacs.

Actually, to be painfully precise, there is a convention, which iterm and emacs might or might not use, by which iterm could conceivably pass the location of single left clicks to the emacs process, but, e.g., mouse drag events and scroll-wheel events never get passed.

So for example when the users drags the mouse, then presses Command-C, `emacs -nw` has no way of knowing the user did that, and if anything got into the system clipboard, that is iterm's doing, not emacs's.

Might I suggest `open Emacs.app` rather than `emacs -nw`? Except for a GNU or Emacs logo that can be suppressed by setting the variable inhibit-startup-screen to non-nil and except for a tool bar that can be suppressed by evalling `(tool-bar-mode -1)`, the result is indistinguishable from a terminal window to most Mac users, but has mouse and scroll-wheel integration.

Thanks for clarifying something I failed to explain. The relative ease with which I can change the size of most of the elements in Emacs is the reason I didn't switch to, for example, Textmate or to Sublime Text when those editors appeared on my radar. Emacs, terminal emulators, Plan 9 port, Chrome and apps based on Electron are the only apps on the Mac I have been able to figure out how to change the size of most of the elements of.

"most of": The size of the menu-bar and pop-up menus is fixed in all of those apps when they are running on a Mac, but Apple made the text in them large and legible enough to suit me.

Setting the scaling to a fractional value in System Preferences doesn't count because the result is too blurry. I never obtained a monitor with a horizontal resolution of at least 2560, which is the minimum needed to set the scaling to 2 in System Preferences.

Emacs's Mac (graphical) interface does that, too, which is not conforming to the environment it is running in.

And there is no user option for changing it to a contextual menu containing Cut, Copy, Paste, etc. (I changed it for myself by writing about 100 lines of Emacs Lisp.)

If MS ever loses the plot and ruins VS Code, I'll probably switch to some fork of VS Code along with millions of other people.

I admit that I have spent a lot of time adjusting Emacs to my preferences (by writing Emacs Lisp code that gets loaded automatically every time my Emacs starts). I am not particularly unhappy about that fact however and will probably spend a lot of time writing code that runs inside vscode if it becomes my daily driver.

Note that I use the graphical interface to Emacs and would've left Emacs many years ago if itworked only inside the terminal environment. I'm guessing you prefer to work in the terminal environment.

Many people don't realize it, but Emacs has been able to act somewhat like a native GTK+ app, a native Mac app or an native Windows app since the early 1990s. "somewhat": right clicking does something idiosyncratic (namely, if there is already an selection, the click causes the start or the end of the selection to move to the site of the click, which is behavior I've not seen in any other GUI; the standard behavior of course being to pop up a contextual menu, which by the way is what I adjusted my Emacs to do by writing about 100 lines of Emacs Lisp code) but left clicking moves the insertion point to the site of the click (the conventional behavior on Mac and Windows) and dragging the mouse does the conventional thing, too.

I like the "just the fact" nature of the terminal environment, but I also like pointing devices. Emacs and vscode (and Plan 9, but Plan 9 has problems that prevented me from ever spending much time there) constitute a happy middle ground between the terminal environment and the overly chaotic environments of Mac apps in general, Windows apps in general and the web. I have yet to see vscode's being used intensively (like Emacs is being used) for tasks other than programming, but would be delighted if vscode or maybe some platform derived from vscode were to start being used like that.

Maybe I will be the first one to write a really popular vscode extension designed for some purpose other than programming.

My visual acuity varies, so I benefit a lot from software that lets me change the size of the elements on the screen. The typical Mac app allows the user to change the size of the text in the main pane, but everything else is a fixed size. In contrast, all the Electron apps I've tested give the user an easy way to change the size of everything, e.g., all the icons in all the panes.

If I had found a way to change the size of everything on one of the Lua-based editors on the Mac, I probably would've switched years ago to one them. (I don't recall their names.)

If I stay with Emacs it will be because learning how to modify vscode, e.g., by writing my own extension, proved too difficult. (I want my editor to be a general interface to information that is easy for me to modify by writing code.)

I'm 58 2/3, and GNU Emacs has been my daily driver since 1991.

vscode however will probably take over that role some time during the next 12 months.