skysight-inc/HackerNews huggingface dataset:
>There should be laws to prevent companies from refusing to do business with "high maintenance" customers without proper documentation and regulation.

Would requiring documentation significantly change what happened here? Suppose that in addition to the letter about termination of service, the Sprint customers also got a spreadsheet showing the times that they called customer service and how long those calls took. Would that help customers? I am somewhat skeptical of the value of this regulatory scheme.
Even Asimov had rouge ai's and killer robots
Using the reserved separator characters wouldn't change that.
I experienced the opposite. But then again, I was living in the north, but onpy visited the south occasioanlly, where there were more tourists about.
Go to your Subnets tab in the EC2 console. You'll see the actual AZ numbers there, vs. the 'random' lettering.
- can only be done in script languages(?)
- syntax errors

I get what you're saying and it can be neat, but I don't think it's universally applicable
‘We cannot make a living’: SF cabdrivers’ debts mount amid Uber, Lyft battle
That's not what I meant by fungible. You don't see CS degree'd people moving into electronics, fluid mechanics or mechanical design.

The math and mathematical techniques for electronics, fluid mechanics, statics, and kinematics is all the same. For example, a mass/spring/damper system is the same as an inductor/capacitor/resister network.
"How to Read a Book" prescribes reading a book 3-4 times. Just the sheer repetition will help you get more out of it.
I also remember since a long time knowing that the surgical tools themselves were disposable (the price for a little bit of steel is nothing compared to the value of the operation for example), perhaps they mean the tool holders or more complicated instruments that hold the tools?
Pretty much everywhere has passing trains with easy access to the rights-of-way for pedestrians. Caltrain alone gets double-figure pedestrian suicides a year, plus some vehicular (driving onto tracks and staying there).
https://www.reuters.com/article/us-usa-surveillance-watchdog... seems to be relevant
The position and identity of all satellites is already public knowledge. It's impossible to hide for long in orbit. It's the satellite capabilities that are classified.
We’ve discussed this at length and I’m squarely in the DO NOT camp. The drawbacks of using non-readable meta characters exceeds the benefits:

1. TSV can be read and imported by almost everything.

2. People can add and adjust TSV files from any editor.

3. What’s the way to insert meta characters again In VIM? And now nano? Argh I’ll just try and copy and paste it. Ugh that doesn’t work.

Just use CSV/TSV folks. Anything more complicated and reach for a better serialization format (json, yaml) and not a better delimiter.
I am starting a small journaling web app: www.quidsentio.com focused on mental health

Still a long way to go, so would appreciate feedback on what direction to go
Wouldn't the optimal one be a mode for your editor of choice?
I have been using pass[1]. Lots of git hosting providers out there and mobile apps. I just have an alias that runs

pass edit journal/$(date '+%Y-%m-%d')

And I run the alias when the mood hits me. Then

pass git push origin

[1] https://www.passwordstore.org/
They're not, but they really help.

https://www.psychologytoday.com/us/blog/the-social-self/2011...
Like a lot of things, #1 is only partly true, particularly if you have embedded tabs.

The number of times I've had to deal with parsing errors because of embedded carriage returns, commas, tabs, etc., sometimes costing millions of dollars is just... upsetting.

It's like JSON... we say everything can parse it, but really what we've got is some approximation that will come back to haunt us... and once you've done all the work to make sure everything is precise and correct, you'd really have saved time if you'd just used the tools we already had in the first place.
journalctl is an executable from the Linux systemd suite. It is used for accessing logs stored by journald. It stands for control.
My personal reasons are:

1) Clojure is more fun, more interactive and interesting.
2) You learn a lot more, more quickly. In Scala it's easy to just fallback to writing classic OOP with a nicer syntax. Clojure forces you to learn FP, meta, logic, etc. much sooner.
3) I'm more productive in it.
4) The interop is way better.
5) Compile times are instantaneous.
6) The community is friendlier.
7) New versions are always backwards compatible, Scala often breaks compatibility and updating is annoying.
It's unusual aberrant behavior for an official GNU project to have its default behavior be printing a banner asking for citations and $30,000 cheques for just one guy. You don't speak for Richard Stallman. I'm sure once this is brought to the attention of the right folks at GNU, the situation will be addressed appropriately. All the other GNU tools I've seen use the startup message to plug the movement as a whole, and explain how its principles benefit you as a user.
A few observations from the article from a surgeon’s perspective . First of all, I agree with the article that sterilizing modern equipment is more difficult. Back when you just had steel equipment, you could just throw them in an autoclave and be sure that they were sterile (with the exception of prion diseases). As the article mentions, a lot of equipment can’t take that kind of treatment and or has areas that are had to access such as long channels.

In additions, not all surgeries are created equal with respect to infection risk. Joint surgeries are some of the highest risk for infection. In fact, when doing open joint surgery, orthopedic surgeons will wear what looks like a space suit with helmet and air supply and work under a giant air suction device to keep the would from being contaminated. Add to that, that they were putting in foreign materials in the form of screws, and you have a recipe for disaster if there is the tiniest bit of contamination. As I have told my patients and medical students, a surgical infection is a life altering event. There is a good chance that you will never be the same after experiencing it.

I think this type of thing will be a bigger issue as we move forward. Surgical equipment is getting more intricate and more expensive. Everybody is pushing to cut costs. Having less equipment for a hospital is less capital costs, but more times that it needs to be properly cleaned, and every time you clean is an opportunity to screw up.

I think the ultimate answer might be taking the responsibility of sterilizing complex surgical equipment from the hospital to the manufacturer. Basically, the hospital would use the equipment once and send it back for reprocessing back to the manufacturer. For a lot of these surgeries, the manufacturer representatives are there at the hospital for surgeries requiring single use stuff likes screws, rods, artificial joints, etc so this would just add to the stuff they are bringing to the hospital anyway. It would be much easier for the FDA is o monitor and regulate a few reprocessing centers instead of every hospital. Simple equipment that you can just throw in an autoclave, can still be done by the hospital. Doing this would also force the manufacturers to think more about ease of cleaning since they would be the ones responsible directly for it.

Just my 2 cents.
I've found that email support varies wildly, and you don't get the quality you might expect.

I've asked simple questions of a financial institution that I trust with most of my savings, and gotten responses that totally ignored everything I wrote except for a keyword or two, as if they were an Eliza-style AI.

On the other hand, I emailed a question to my health insurer, and I got a completely sensible, intelligent, and helpful response.

Even in person, I frequently ask a simple question and people act like I've got two heads. Sometimes the businesses they work for are objectively honest and competent, but somehow they can't answer a really basic question. Like the other day, I was replacing some fire extinguishers and I realized I had just signed off on new ones without understanding the UL rating. Granted, it wasn't that hard to find an explanation online after a few minutes, but someone who works for a business that sells them to everybody in the area should be able and willing to explain.

I don't think this can all be economically rational optimization.
I don't mean the math one orthogonal to the space-time one. I mean that dimensions are orthogonal to each other whether in math or space-time (except special relativities).
What if you're using multiple programming languages?
Now the auth-service is faking user data, but returning replies that I can actually use in the php-service to generate the correct package list
I find it so interesting to see the sort of bubbles that people live in and believe in.

There is a big % of the sp500 companies with huge infrastructure inhouse, legacy system and sysadmins generating most of the money in the world and yet you think that kids that can script against a cloud API have them in their pockets.

I really suggest looking outside the bubble.
2. More accurately, people can screw up TSV files from any editor. Have you not seen embedded spaces used instead of tabs and totally mess everyone up?
You drink green (as opposed to mature) white (grape color) wine cold, specially in the summer.
We took the wrong path quite some time ago. Most of the POSIX utils like sort, cut, grep only support \n (or sometimes \0) as row separator.
3. If you don't know how to use your editor, maybe you should learn. If your editor can't insert even all the characters in basic ASCII, it's not an editor.
The main findings of the research were:

• Psychiatric diagnoses all use different decision-making rules

• There is a huge amount of overlap in symptoms between diagnoses

• Almost all diagnoses mask the role of trauma and adverse events

• Diagnoses tell us little about the individual patient and what treatment they need
I think that you're talking about the Lemons races.

To be clear -- this mechanic (forced sale of vehicle) is not common in auto-racing. Very few sanctioning bodies do this, and they're all bottom-barrel (funding wise) groups like the Lemons endurance events or derby-style cars that aren't expected to have any longevity, anyway.

Also, that mechanic has been cheated numerous times. Since the Lemons series doesn't hold the car in escrow or in any other financially or legally binding manner it's up to the seller to be polite and abide by the rules. Plenty of people haven't. They're not usually welcomed back as drivers', they just move to another team and cheat there, instead.

The real way to do what you're trying to achieve (create a fair place for those with limited budget to compete in) in automobile racing is by strict classing rules and strict scrutineering. A good example of this is SCCA Solo autocross racing. It's extraordinarily cheap to compete in, and highly competitive. This is achieved through strict rules, tons of bureaucracy, and the threat of tattle-tales in the form of competing teams or drivers.

I don't know how that moral can be related back to surgery, but I do believe the Lemons' style of fairness-by-threat-of-sale is flawed.
What was insane about talisman is that it tried to render the tiles "just in time"

Other tiled renders (both powervr at the time and all modern mobile GPUs) would write the color tile back to an in-memory color buffer and scan out the image to screen from that. They also had fall-back paths if a game does something that can't be expressed in a pure tiled way (like many post-processing effects).

They would flush both the tile color and tile depth out to in-memory color and depth buffers buffers and then pull those back in to restart tiles later. Nvidia's Maxwell and later desktop GPUs take this to the extreme and flush those tiles in-and-out so many times per frame.

Telisman doesn't (can't?) do this. It tried to render all the tiles it needs for scanning out the next 32 lines into a small on-chip buffer and scan those out while rendering the next set of tiles for the next 32 lines.

This saves on memory bandwidth but the whole approach falls apart if you try to render too many polygons. Instead of frames being late, parts of the screen disappear.
You're putting words in my mouth and totally misrepresenting my point.

I never said we shouldn't care about Kent State, nor have I said that it was unimportant.

What I said is that Tiananmen was several orders of magnitude worse, and while anyone in the US can look up Kent State and other horrible occurrences in their history books, many of them found in schools, or in any other place they'd like, people in China cannot look up the Tiananmen Square massacre.

I am replying to someone claiming that the US has done the same with Kent State as China has done with Tiananmen Square and that the events were equal to begin with. So if you can show me where the US has tried to cover up the fact that Kent State happened at even 1/1000th of the effort that China has gone through to cover up Tiananmen Square, or that the loss of human life between the two is similar, this might be a productive conversation.

In the mean time, you're responding to a point I never made and words I never said.
Cool that there are some specialty tools in this space and will use if I hit that performance challenge.

Minor nit, I found the performance table (https://github.com/eBay/tsv-utils/blob/master/docs/Performan...) confusing at first and second glance. Alternating colors indicate.. different OSes? That doesn't seem to be the important message to convey as you are trying to show the speed of your tool and not the OS. Recommend to use the coloration to provide differentiation between tools instead of OS.
So..why not use XML?
> XML is awful

I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up.

The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
For neurosurgery, when operating on a patient with suspected prion disease, the surgery will be done with disposable instruments as much as possible. This may mean however that the surgeon will have to use a hand drill, instead of a power drill.

For the other cases without prions, normal sterilization works. And you don’t want to throw away all your equipment after each surgery. A neurosurgical power drill can cost around $20,000 - $40,000
Avant UI Kit
Hi.

I'd like to show the "Avant UI kit" to the community.

- https://www.avantui.com/

Please let your suggestion for a future implementation.

Thanks is advance.
Stop commenting on every HN post, thanks
Try reading a good text multiple times, even to the point of memorizing it. Especially in the past, many cultures viewed memorization as essential to truly engaging with a text. Another way to engage more deeply with a good, classic text is to read commentary on it.

Obviously you can't treat everything you read this way, but for a few really good classics this has been a fruitful approach for me. For a novel, maybe you could just memorize a few passages. When you have the words rolling around in your head, you'll find that you recall them at just the right time.
To explore any vast search space, you have to apply some randomness though.

Precisely because you can never explore more than a tiny bit, you can't know your snap judgements are not systematically blinding you to important stuff without just trying things at random sometimes.
It's not that, it's actually because of the best and most reasonable of reasons: the maintainers and core committers don't use / aren't interested in iOS.

They aren't opposed to it, and they give advice and helpful comments to those who want to try it.

But, this is just one of the many places where Apple's authoritarian platform model shows its disadvantages. Syncthing is written in Go, but Apple didn't provide a good story for doing Go development for iOS, and because of their lockdown rules, nobody other than Apple can.

Therefore, to get Syncthing running on iOS, you'd need to do a complete from-scratch implementation in one of the languages Apple allows you to use. So it is a relatively huge effort. A few people have tried, but nobody's completed anything very compelling.

[1]: https://forum.syncthing.net/t/on-syncthing-ios-port-again/89...
What subcontractor would accept this arrangement? I sure wouldn’t. It’s like an evil genie situation. You’re never going to define customer satisfaction metrics in a way that won’t end up being gamefied to circumvent the spirit of what you’re supposed to do to help customers in order to maximize some metrics.

This issues can also be related to the company itself. What if there’s an undisclosed bug in your randomization process based on IP or time zone or something that tilts the satisfaction metrics via an almost impossible to detect skew in the customer distribution routed to subcontractor A instead of B? What if you the company introduce a policy or product change that makes customers unhappy even if the subcontractor is doing exactly what you asked them to do? Or what if subcontractors realize the only way to make people happy is to do something really expensive or unapproved by you?
I don't think it will be long before Firefox is that 'specialized piece of software' needed. It always pays to think of how something could be possible in the future rather than why it can't work now.
Does timber use Elixir for their ingestion pipeline?
The most lonely are old people I think.. but the ones that live in senior housing tend to do a lot better. Kids in college also do well since they are among their peers.. One idea to push this forward is mixed use housing. Parents want to find other parents so their kids can play. Teenagers likewise. So you need all ages in your little "village".
>It's the satellite capabilities that are classified.

Welp... now the world knows the satellite's capabilities and that said satellite was probably USA-244[0].

[0]https://en.wikipedia.org/wiki/USA-224
I have the same problem at my job and a very similar process (biggest difference is that we require unanimous consent before merges). My overall opinion towards code reviews is that they don’t work, software should not be seen as a static entity that is released and completed (like a building), but as something that requires constant upkeep (like an garden). Since our process was established 20 years ago (while I was in elementary school) time has been cemented it by bureaucratic inertia. So my approach is not what you can do to your process, but what you can do as an individual within your existing process.

The idea behind my approach is to convince the person to do the right thing on their own. First step is to mentally prepare, as if you were an actor preparing for a roll as a villain. Your attitude should be “any code not written by me is garbage, and should be completely rewritten.” This attitude (which you should not adopt in your general professional life) will help you get through this ordeal. Next step is to poke as many holes in the code under review as you can in the time you have. Don’t stop on the diffs, do it for the whole code base. If the person touched the code they are responsible for the whole thing. Send as many issues as you can back, cc their management. This will make some people angry, but it will be temporary and most importantly buy you time.

Management will be aware that their are issues with the merge, but they don’t have the time to review your comments and understand the issues, they have other problems. They don’t want doubt in the work going out and will do anything to make themselves feel confident. They will put their trust in you and will not allow the merge until you say it’s good. You are the gate keeper, you hold the key.

Now it’s time for the real code review. The person having the review now depends on you. This is where you get as friendly as possible. Complement sandwich works here “I like your code, there’s just a few things that need to be changed, this looks like it’s going to be a slam dunk, we’re almost there, good job so far buddy.” The most important thing now is to identify specific issues that have bounded solutions (not wild goose chase ordeals). The more specific and more bounded, the requests are, the happier people will be and the faster people can move on.

The whole idea here is to develop an understanding with people. You’re going to tell people what you expect, and make it as easy as you can to carry it out without significant impacts to their schedule. As soon as they deliver on your requests, you approve. You go to management and say the code looks a lot better and you approved the peer review. Everyone looks good, everyone is a winner here.
I'm an old school sysadmin that recently has been making a buck doing "devops consultancy". In reality, my job is fixing stuff that the developers "automated" (because I don't really think an automation that is not performing any work is an automation at all). I've seen some scenarios that are hard to describe outside of my sysadmin expertise with something other than silly.

Not so recently I hear a lot of some Jessie guy, brilliant, who developed and amazing product and was a very good engineer. His team all made clear that this guy was so efficient that he was in charge of a lot of stuff; sadly he didn't documented a vital step of the development pipeline that was causing all the builds to fail and he left the company years ago. His team, that was at least capable enough to keep the ship afloat for more than two years without Jessie who was the driving force and main engineer, combed the documentation and code but couldn't find the problem, they appear to be pretty good coders and the codebase was clean enough that I do not question their capacity as developers, but the problem was too deep, mainly because as they told me, this Jessie guy was pretty great.

Well, actually the problem is that Debian Jessie reached EOL some time ago, and this guys recently they migrated the build server, losing all the image cache. They were unfamiliar enough with errors on the package manager and with the shadow of this Jessie guy that even if they found something about the backports url, they didn't thought it was related to their issue. Just changing the repo url was enough to keep them working again so I could take a look at the rest of the stuff.

That's just the silliest one I can think about, but just one of many. I'm certainly not over impressed with developers doing "devops" by themselves.
> If you are going to use them as expensive tape then by all means, but otherwise I have serious doubts about their usefulness.

Only writing is more complicated. Reading is still simple and fast; and random access reading is fast, unlike tape.