willeh

Perhaps `professional` is too narrow then. I think the power differential is an enabling factor for behaviour like this. While there certainly are creeps in normal dating situations, they are often easier to avoid. This story is very much about how this power differential allows one person to abuse another like this.

Being aware of how this affects human relationships is neither unrealistic nor unhelpful. It is something to take seriously and talk about in groups where it could arise.

This may be a tone-deaf sidetrack but also perhaps an important piece of advice for some. There should be an impenetrable barrier between ones love life and ones professional life. While there are certainly people who have met their significant other in a professional setting, there are much better ways of doing that, especially nowadays. By striving to keep this separation water tight we can avoid both unwanted advances and false allegations.

The above is not comment on the allegations in the post, any more than if everyone followed the above basic principle we would not have to deal with disturbing stories such as this one. It is important that stories such as this one are told but perhaps with the names left out.

Can't tell if you're joking but one of the selling points of Microsofts paid versions of Visual Studio used to be good support for writing classes using UML. Microsoft is the O.g low-code company spending most of the 00s making people do things in diagrams and form builders of different kinds.

Any benefit that a "buyer of last resort" entails can easily be provided by either government or derivatives markets.

Bitcoin takes away resources (energy and semiconductor manufacturing) from socially good things. It is much better when people admit that they are greedy than when they try to paint their greed as some great effort towards saving the planet. This goes for both traditional money managers and HODLers.

I'm hoping for a correction soon, as much as we might all end up unemployed, it would be a great pleasure to see these SV thought leaders cut down to size.

Don't do colo, do a rental dedicated server instead, its almost the same thing but much cheaper in practice, and it won't mean having to travel to a data-center during work hours. If you absolutely want to manage your own hardware but it in a cabinet in your house instead.

There are plenty of regions in Europe that have similar histories and few countries in Europe are really that old, even states with long histories have not had constitutional orders lasting more than 50 years. Finland was a part of Sweden for 600 years, Denmark part of Norway for an equal amount time. Neither of those facts in any way reduces the Finnish or Norwegian people's right to self determination.

Waging aggressive war is a violation of international law - The state of Ukraine is the legitimate successor to Ukrainian SFR and if Russia has any claims on its territory those must be pursued through legal means.

There is nothing complicated about the Ukrainian question, it is simply a part of Putin's strategy of death by a thousand cuts. Last time that strategy was used Europe was thrown into a conflict that made the world say never again to nationalism. The Russian people would have done well to listen to their grandfathers now that this conflict is all but forgot.

And India was part of the British empire, Mexico (then called the viceroyalty of New Spain) a part of Spain and the list goes on. Might makes right belongs to a bygone age and people are entitled to self-determination.

To decline to stand up to dictator - nay, a tyrant - such as Putin makes one a coward undeserving of the liberties they were born with.

I think the many point of the article isn't necessarily that it is easy to construct models in terms of lines of code but that any tweaking of the model is dominated by increases in data-size. Why pay for a PHD when you can invest in more data instead.

None taken. My comment wasn't necessarily about Free vs Open source software, but about leaders for the free software movement. From my point of view RMS seems like a strong leader from a technocratic perspective, he has written significant portions of the code for the GNU "operating system" and of course is still the leader of the GNU project. His means of accomplishing his political goals are practical - writing software with copyleft licences and boycotting other alternatives. To accept RMS as a leader we must take a technocratic view we ignore everything but his performance, in a narrow sense.

I myself am no fan of RMS (although I'm also critical of the way he was "cancelled") so it is much harder to put justification for an opinion I don't share to paper but I hope this clears up my previous post somewhat.

I hope that I'm wrong here and there is evidence of actual bots, but as far as I can tell you're making this judgement based on the fact the people signing the RMS support letter have Russian sounding names. First off, yes I don't doubt that the totalitarian oppressive and oppressive governments are using this type of technique, in fact they are probably using it a lot because it is highly effective. However, it seems exceedingly unlikely that they have any interest in a spat in an, on the whole, insignificant professional organization.

I think it is worth reevaluating your opinion, as understanding the other side of an argument is useful and helps us understand the world better. Generalising, a bit in my experience Russians tend to be slightly technocratic valuing pragmatism over ideology, which seems natural considering that it was beaten out of them by a series of absolutist despots.

Still their opinions are valid even if most people in Europe and the US, no matter their political beliefs, will consider RMS to have perjured himself as an ideological leader to the extent that trust can not be mended, and consequently must resign.

I agree, it definitely seems that the phrasing there needs work. Overall I would say most RFCs are well substandard especially when compared to ISO standards which tend to be extremely precise. That being said, interoperability within tech is amazing so perhaps there is something to be said about the idea of loose standards and working code after all.

`.well-known` is already used for validation for many things, perhaps most crucially acme-challenge which is used by LetsEncrypt to issue domain validation certificates. LetsEncrypt is trusted by all major browsers at this point so it seems that the consensus is that .well-known must be kept secure at any cost. So even if you disagree with `.well-known` it must de facto be kept in the inner-most ring of your security model.

Most importantly Auth0 was beating Okta on execution. Auth0 was leaner and would soon get to feature parity for both use cases. Without this deal they would slowly have lost ground to Auth0.

Growing up as the typical nerd, I used to think that trust was something that needed to be eliminated, that other people weren't worthy of trust and that we all ought to be using TOR, bitcoin, I2P. All our chats be over XMPP with OTR messaging. But growing up, and getting beyond the world of early adulthood I've come to realise that most people can be trusted most of the time. Who doesn't instinctively look away when someone is typing in a password, most bosses aren't trying to scam you out of your pay check. In fact most people instinctively help others - even giving them a little push along.

As amazing, magical and occasionally necessary things like TOR, bitcoin and I2P are what truly is wonderful is that basic trust, that small but significant ∆, much more than clever algorithms and data structures is what makes our lives work.

Truly fantastic stuff. I don't really have anything to add other than to say that this made me feel happy about what I do for a living. So much better than reading flamewars camouflaged as blogposts :)

3) Is largely not true, the EU is largely heterogeneous when it comes to personal bankruptcy laws. The fact that unsecured consumer loans are as cheap as secured consumer loans (e.g. car loans), in many EU countries, shows that it is very to get rid of debt permanently. In the country I know best a personal bankruptcy means that you have to keep paying your debts for a period of 5 years before they are forgiven. During this time you must live on $500 per month (excl. rent) the rest goes to the creditors.

Encryption means speedy deletion so there is still value encrypting even if the key isn't protected. But that's probably not the reason for Apple always encrypting things with the key of the Secure Enclave. I think the reason for this design is to make the full system easier to reason about, which seems like best practice.

Except if you're using Homebrew where nothing is signed, so signing is not as ubiquitous as you seem to think.

But signing is largely a moot point as people will follow the instructions on the website where a clever attacker would simply create their own cryptographic keys sign it and provide instructions for adding it to your keychain to the compromised website. Public key crypto does not solve establishing trust for an actor. It can only do so through delegation which as we have seen with the deprecation of EV certificates (CAs no longer being trusted to establish the identity of legal persons) is not something that is easy to get right.

Certainly it is better to trust the maintainers of your operating system/package manager than a random website. However they only sign things where they have done due-diligence on the project, which is a slow process, too slow for projects with faster release cycle such as Docker or Rust.

As opposed to downloading a binary and running it? We don't verify what the binaries we download contain, why do it for a bash script?

Never understood forex trading myself, and I'm by no means a trading professional but it has struck me that most Forex brokers seem extremely shady. Seems like an extremely risky asset class with no natural tendency to go up and to the right. So I'm curious if anyone on HN can explain the thinking behind stuff like this.

This is purely my personal opinion, but the wikipedia community seems like one of the most toxic communities on the web. The people contributing to WP - the editors - seem more concerned with coming up with Kafka-esque processes to introduce to the community than making the actual work of making an encyclopaedia. Perhaps the only area where editors are as zealous they are about creating obscure processes, is in policing what content should they should fit into the their volumes. Truly, it is a bureaucracy expanding to meet its own needs. One that attracts a certain group of people, who have a certain view of social interactions, that necessitates certain procedures for social interactions, giving rise to articles like this one specifically.

For the rest of us cooking up an apology from a recipe is feel insincere, an apology is a ritual sure showing how its done ruins the illusion. On a higher level this type of process-over-vision thinking has ruined the goals and ideas of Wikipedia, a site which in the 00s seemed world-changing and lead it to it's decline in the 10s and to what I predict will be its fall in the 20s.

I hope to be wrong about WP, I hope for a new wave of optimistic idealism to swallow up tech again, bringing about a new era of amateurism. But with the professionalisation of even the free software community I have, I must admit, all but given up hope.

I'm a long time user of Prelude myself and it is absolutely terrific. I like my Emacs to be well Emacs and prelude as opposed to many other configs fits that description perfectly. A huge thanks to bbatsov for saving countless hours of configuring.

I don't agree with the author that the quality of the team is what determines if a mono-repo is appropriate or not. It doesn't really matter if you use a mono-repo or not, what matters is what individual engineers are empowered to do.

If engineers or even team-leads don't have permission to create a repo themselves well then you're probably going to see benefits from a monorepo.

At the same time if you have say a ~100 people sharing a repo then you have to make sure that you have tooling that allows each team to customize their building and test environments themselves, which is hard because many CI solutions assume that One Repo = One Build status. Implicit in the author's reasoning is the principle that good engineers don't make mistakes; they don't break the build, not ever. But of course they do, everyone does, and if you have a hundred developers builds will be broken and people's productivity ruined.

Perhaps because we're an industry so prone to failure we keep looking for that one solution, that given a good team makes all problems go away. Agile, XP, Monorepos, Containers, Microservices: we tell ourselves will solve our problems and get those pesky business people off our backs for good. But they won't and never will.

What really matters is enablement, how can we get our code into production doing what it was intended to do without having your toes stepped on all the time. If you design your processes and tooling around enablement not the cargo-cult flavour of the month buzzword invented in the modern beautifully architected, yet completely open office spaces of one of the FAANG companies, then maybe then you can get some actual results.

There are definitely use cases for this, for instance you might have some command line application that uses standard io. Sure it might be adapted to have support for web sockets natively, but this of course takes time. And as the old adage goes time is money.

And sure you might be upset by "slow" websites, but for the small consultancy productising their scripts, it might make them - dare I say it, a quick buck. In the end the invisible hand of the market decides how much money is invested making websites fast and that is what guides the design of the technology being developed.

Perhaps it is you who fail to see the big picture.

> Can you explain to me how the deletion policies work?

Disclaimer: The GDPR hasn't been the law of the land for a year, so there is little precedent.

It is fairly simple, the GDPR requires that companies that control identifying information about you (or somehow delegate this), have acceptable reasons for doing so (user consent/other law/etc). When some entity controls your information the GDPR gives you certain rights. The key point here is that the company is controlling your information not you, whereas the scrapbook is under your control. The loss of control of the information creates in my mind a moral obligation to treat it a certain way. One of the rights that the GDPR confers on the data-subject is the having data deleted, this right is not absolute and if you have any other grounds (e.g. AML regulation) for keeping the data then you don't have to delete it. Additionally, deletion doesn't have to be immediately consistent, so you won't have to go into old backups and delete the data there.

TL;DR: If someone asks you to remove something, just delete it from your SQL database, and that's it.

There are two key costs for startups implementing the GDPR:

1. Privacy by Design - Make some efforts to design the information systems in your company in a way that promotes privacy. 2. Demonstrating compliance - This tasks scales with company size, you might start out with a boilerplate privacy policy, but as you grow want to be more diligent.

I really don't blame the author here, sure there was an issue with the sample code - but come on it was sample code. If someone is implementing user uploads they should really do the due diligence and understand what the sample code does.

To be honest I'm not really that surprised that the vulnerability stayed hidden for so long; many PHP users are hobbyists or come from a more traditional "webmaster" background. This is not to say that there aren't good PHP programmers, just that there is a large group of novices.

I'd say it is normal. Generally you wouldn't find equations describing some proposed model, instead you would find "equations" describing the statistical observations. This paper, however, isn't empirical. It instead proposes a theoretical framework, based on the earlier studies. It argues (hopefully soundly) from the premises of the quoted studies to the conclusions it reaches. The point of the research isn't to present this is exactly how this behaves in mathematical terms, or even suggest a mathematical model for how it could work. Instead it presents a semi-formal description of how it could work, so someone can come up with an experiment trying to establish if it really does work that way. Once some evidence is obtained, you go from there to the more mathematical models.

Its hard to formalise things especially in fields were you're far removed from the maths. So rather than spending a ton of time making a model that is probably fundamentally wrong, you make an approximation in informal language. Scientific discovery is in my mind is always a balancing act between verifying propositions (which don't really _mean_ anything) and sharing thoughts (which don't really _prove_ anything).

In cognitive neuroscience semi-formal descriptions are great. In comp-sci, give me the equation already!

I think he is referring to the fact that you use a fluent builder interface when building protobuf messages so you chain together a bunch of `.setFoo(myFoo).myBar(myBar).build()` to build your protobuf, while in Kotlin it is idiomatic to write `foo = myFoo` and `bar = myBar`. There are ways around this with `.apply` in Kotlin, but it all feels really clunky.

That said if you want a systematic don't make me think approach for backward and forward compat I think protobuf/GRPC is the way to go you just need to learn a few rules for how to do it and you're set. In terms of static typing protbuf doesn't really get you that much because in order to get backward/forward compat you can't have required fields, so everything needs to be null-checked or have default values.

I might be irrational but these "someone on the internet is wrong" style articles are terribly unengaging.

Getting an Internal Server Error at https://cdn.jsdelivr.net/polyfills/polyfill.js