belak

I wonder if this is an effort to combat pages which post a short clickbait description and require you to click "read more" to see the full description, and often post the link in the comments. There are lots of sites (Polygon immediately comes to mind) which are notorious for doing this as a way to get fake engagement which boosts their posts which gets more clickbait engagement.

I know it's all speculation, and this does come across as more monetization creep, but I can't help to wonder if there's an underlying reason beyond "line go up".

I'm have no experience with abstracting away the backend, but Dockerizing is actually pretty easy now - there's an offline mode[1] where you can have sqlx generate some files which let it work when there's no DB running.

[1]: https://docs.rs/sqlx/latest/sqlx/macro.query.html#offline-mo...

I think you're missing much of the context and are misrepresenting what happened.

As far as I'm aware, there was no crying he didn't want to work with people, but there was a frustration that he was not open to having a Markdown "standard". To the point where he actively opposed efforts to standardize it, at least under the name Markdown[1].

This is legally and technically fine, as he owns a trademark for Markdown, but when you combine the inconsistent application of that trademark (GitHub Flavored Markdown is seemingly fine, but Common Markdown was not), along with him calling it "Jeff Atwood's crusade" and mocking the effort[2], it's not a great look and resulted in quite a few frustrated people.

As an open source project, you're right that he doesn't owe anything to anyone, but that doesn't mean people have to be entirely happy about how the situation was handled either.

[1]: https://blog.codinghorror.com/standard-markdown-is-now-commo...

[2]: https://soundcloud.com/thetalkshow/ep-88-cat-pictures-side-1, around 1:15

They introduced Bitbucket Pipelines around when I left, about 7 years ago.

- https://bitbucket.org/product/features/pipelines

- https://bitbucket.org/blog/introducing-bitbucket-pipelines-b...

That's fair - I added "are working on a specific problem which needs a more complicated setup" to my original comment as a nicer way of referring to edge cases like search engines. I still believe that 99% of applications would function perfectly fine with a single primary DB.

This is absolutely true - when I was at Bitbucket (ages ago at this point) and we were having issues with our DB server (mostly due to scaling), almost everyone we talked to said "buy a bigger box until you can't any more" because of how complex (and indirectly expensive) the alternatives are - sharding and microservices both have a ton more failure points than a single large box.

I'm sure they eventually moved off that single primary box, but for many years Bitbucket was run off 1 primary in each datacenter (with a failover), and a few read-only copies. If you're getting to the point where one database isn't enough, you're either doing something pretty weird, are working on a specific problem which needs a more complicated setup, or have grown to the point where investing in a microservice architecture starts to make sense.

The article is great, but the title here has been editorialized a bit. I'm not super familiar with HN, so what's the best way to get that fixed to match the actual article?

Thanks! Good catch! I was going off blog posts and didn't see that there was a download for RC1.

The original plan was to release in February, but in the Beta 2 release [1], they said this: "Because we are taking the time to issue a second beta, we now expect that the Go 1.18 release candidate will be issued in February, with the final Go 1.18 release in March."

It looks like there are still a few release blockers [2]. I'd imagine RC is fairly soon though.

EDIT: as mentioned by _fz_ below, RC1 has already released. Seems like the full release will most likely still be in March.

[1]: https://go.dev/blog/go1.18beta2

[2]: https://github.com/golang/go/issues?q=is%3Aopen+label%3Arele...

It's also available as a mirror at https://github.com/golang/pkgsite. All the golang.org/x/* packages are thankfully available there, making them pretty easy to find.

The short version is "it depends". Essentially, each separate Wayland compositor needs to add support for the nvidia driver (or the driver needs to support more standardized APIs).

Gnome and KDE support Wayland on nvidia hardware (though it's a bit rough around the edges). Wlroots (and therefore Sway) doesn't because they don't want to have a separate code-path for one driver which doesn't want to support standards and because the APIs the driver does support wouldn't work well with the code model of wlroots.

I've seen endlessh[0] referenced in the past. Here's an article that talks about this and other SSH tarpits[1].

[0]: https://github.com/skeeto/endlessh

[1]: https://nullprogram.com/blog/2019/03/22/

Oh cool, I missed this in the 1.14 release notes. This partially fixes it, but it's not easy to implement multiple interfaces with overlapping functions because you still can't implement multiple functions on the same type with the same name.

On your website, the only remote position listed is Senior QA Analyst. Are other positions open for remote work, or only the ones explicitly listed?

Hey all, this is a project I’ve been working on and finally decided it was ready enough to show it to the public.

The idea was just to build an SSH server for hosting repos which can be configured using git to show that something can be built that’s pretty solid and doesn’t depend on openssh.

It’s based on my past work on the gliderlabs/ssh library, the Gitea SSH server, and some experiments with git internals in go.

For me, I prefer Django, but I haven't used Rails in a number of years. In general I prefer Python over Ruby because it's more explicit and less magic, but Ruby definitely has its conveniences.

That being said, I am not a Ruby developer, I am a Python developer, so I'll try to address these points as best I can from the other side of the equation.

* Authentication - this is fairly simple to address. It's a fairly easy-to-use pluggable backend. It's not very hard to write a system to replace the default which would let you log in using other credentials. Also, a few years ago you couldn't replace the default User model - that has since been changed.

* Asset pipeline - fair point, but I prefer to keep my assets separate from the backend if possible - my current work project has a backend API in django with a separate frontend repo with all the JS/CSS

* Configuration - the best solution for this I've found is django-environ[0]. Alternatively, the built-in `DJANGO_SETTINGS_FILE` environment variable lets you specify a different base config file.

* Sidekiq/Celery - The API, I'll give you, however it's fairly easy to configure Celery to use Redis

* Mailer previews - I've used mailhog[1] before. This gives you a local mailbox to test with and will be closer to your final configuration anyway.

* Better security - possibly by default, but I haven't had any issues with django-rest-framework in the past

* Testing - pytest with pytest-django is also great to work with.

* Django ORM vs ActiveRecord - I don't have a ton of experience with ActiveRecord but I like the Django ORM. There's also SQLAlchemy, but it's a bit odd to rip that out of django if you don't need to.

I like Django because it's solid out of the box, but still provides a way to extend the core to be as flexible as you want. I assume it's possible to do this with Rails, but that's not my area of expertise.

I do appreciate you outlining things you like better as opposed to just saying "Django is terrible". I'll definitely have to try Rails again and see what I think of it now.

[0] https://github.com/joke2k/django-environ

[1] https://github.com/mailhog/MailHog

Hi everyone! I’m the author of this project and finally got around to writing up a short intro and my thoughts on the matter, so I’m considering this an initial release. I’d be happy to answer any questions about zsh-utils you have.

True enough. I found the things mentioned in the article interesting because you also lose things like Google Web Fonts and a number of services which depend on the Google Maps APIs for mapping.

Unfortunately, I won't be able to completely disconnect because I've got a number of friends who share photos through Google Photos (and I would like to keep access to those), a number of friends who only use Hangouts (not sure if that's better or worse than FB Messenger), and YouTube doesn't have any real competitors.

There's an interesting article on Gizmodo (so please take it with a grain of salt) about trying to cut Google out of your life - long story short, it's surprisingly hard and some things you wouldn't expect will break.

https://gizmodo.com/i-cut-google-out-of-my-life-it-screwed-u...

It's "a package of items used by medical personnel for gathering and preserving physical evidence following an allegation of sexual assault."

They're generally used for gathering and preserving DNA evidence in the case of sexual assault.

https://en.wikipedia.org/wiki/Rape_kit

This reminds me of the Final Fantasy IX strategy guide. It integrated with Square Enix's Play Online service but now that FFIX was removed from Play Online, none of the links work any more and the guide is pretty much useless. I'm sure we'll start to see more of this in the coming years. It's not really sustainable to keep a website running forever.

I do appreciate some of the sentiment here. "Organize your apps inside a package", "Keep migrations safe", "Don't cache models" and "Avoid GenericForeignKey" are the ones I agree the most with, so I'll go over some of the others. Some of the other migration-related ones I don't have a strong opinion on...

> If you don’t really understand the point of apps, ignore them and stick with a single app for your backend. You can still organize a growing codebase without using separate apps.

This is still possible, but gets very painful down the line when you need to split it out into separate apps because detangling the mess will be next to impossible. I generally try to think about apps as distinct features which sometimes helps in splitting out the functionality.

> Explicitly name your database tables

If you're using apps this provides a nice separation between apps and makes it easier to see where data is coming from, rather than having custom table names that could be coming from anywhere.

> Avoid fat models

Models are really the only core location you have to add functionality to an object without worrying about copying it down the line. Fat models can be a pain to deal with, but it's better than the suggested alternative of building an additional access layer on top of the models themselves. Models are Objects and it makes sense to use them as such.

> Avoid using the ORM as the main interface to your data

Why? Building an additional layer on top of an already useful layer to do things it already supports seems a bit crazy. The part of this that I think is the strangest is this line: "Apart from signals, your only workaround is to overload a lot of logic into Model.save(), which can get very unwieldy and awkward." Those are the main two workarounds... and it's interesting to see them say "Be careful with signals" the section before then admit they're useful but recommend not using them.

Those were the main things I noticed. There are obviously some useful tips in here, particularly around migrations, but the portions where they go against direct recommendations relating to django.

If you're looking for a good book on recommendations from people who have been writing Django applications at scale, I strongly recommend Two Scoops of Django (https://www.twoscoopspress.com). There's a new version (https://www.twoscoopspress.com/products/two-scoops-of-django...) coming out soon which may be worth checking out (I've read previous versions and am recommending based on those).

One of the projects I worked on in the past had a legacy app which contained most of the core logic... and as the site grew, new apps were created because it got impossible to manage that one massive app. Splitting it into multiple pieces was incredibly painful because the codebase wasn't designed for that... so while I think this may help you get up and running faster, it will probably cause problems down the line.

They actually reunited a few years ago, have been playing shows since then, and are releasing a new album this year. They didn't get back together just to play a show at a tech conference.

https://en.wikipedia.org/wiki/LCD_Soundsystem#Reunion_and_ne...

I do agree with the general sentiment here... both emacs and vim are primarily editors. However, it's also worth noting that emacs is much easier to extend and change than vim which is one of the reasons people do so many things in it (hence the "Emacs is a decent operating system lacking only a good text editor" joke). Handling email, chat, all git operations and more is common in emacs, but fairly rare (at least in comparison) in vim.

There's also spacemacs (for a large config) and evil-mode (if you want to get into the nitty gritty details) for using vim bindings in emacs. Doing the opposite would be a much harder feat.

I love both editors... and there's a reason I have both a vimrc and an init.el. vim has the advantage of being pretty much everywhere (so it works really well when editing on servers), and has awesome modal editing, but emacs works really well for local development where I can make sure I'm using the right version and have it tweaked to work exactly how I want.

I don't think that one is better than the other, just that they have different use cases.

He isn't being silenced or banned as far as I know, but there were multiple people calling for his removal as a part-time partner with YCombinator.

Sam Altman summed it up and explained his decision in his blog: http://blog.samaltman.com/the-2016-election

You'd be surprised. Go actually has a supported SSH library which is a fairly decent protocol-level implementation. To actually get a "shell server" you would need to implement handling of SSH sessions (as described in the RFCs) but all the low level stuff is taken care of.

EDIT: As an example, the gogs project has implemented a small ssh server so people running it don't need to hook into OpenSSH, which relies on specific versions of OpenSSH to be performant. See https://github.com/gogits/gogs/blob/master/modules/ssh/ssh.g...