Hacker Newsnew | past | comments | ask | show | jobs | submit | loodish's commentslogin

Yes. Significantly safer than a Windows system in the default config.

If you expose a Windows server default install to the internet it will be compromised in days. (I don't know how. I do know AWS was very unimpressed with me.)

In contrast Linux systems are often set up that way without issue.


The finiteness of fossil fuels isn't real in a practical sense.

The globe burnt about 8.8 billion tons of coal in 2024. Which is a huge amount. This is the peak, most estimates are that we will reduce from there.

Australia alone estimates that it has 147 billion tons of economically recoverable coal. That is Australia alone could supply the entire globe at peak usage for over 16 years. And Australia only has about 14% of the globes coal reserves, we can keep burning coal at this pace for at least the next hundred years. And it a hundred years the scope of what we consider to be economically recoverable will have expanded greatly, further increasing our supply.

We will cook ourselves before we run out of fuel.


There are much faster responses available.

For example France could gift or sell Denmark some nukes, possibly with a Rafale as a launch platform. Denmark would be an instant nuclear nation-state.

I'm not sure there is the political will though.


If you breach the LGPLv2/GPLv2 licence then you lose all rights to use the software.

There's no penalty clause, there's no recovery clause. If you don't comply with the licence conditions then you don't have a licence. If you don't have a licence then you can't use the program, any version of the program. And if your products depend on that program then you lose your products.

The theoretical email would be a notification that they had breached the licence and could no longer use the software. The obvious implication being that AWS was wanting to do something that went contrary to the restrictions in the GPL, and he was trying to convince them not to.


I like cron jobs that run during the work day. If something goes wrong I would prefer to handle it at 10am rather than 10pm. Why make life unpleasant?

If it really needs to run during a low load period I line it up for 6am work time. Again so that if something goes wrong it leads into the work day rather than disrupts the on-call too badly. 6am also provides a daylight savings buffer either way so you don't have to care. Recent work has all been on 24/7 operations though.


Folks that really care about security go for tamper evidence.

For example you can get a filing cabinet which has a lock and a counter that ticks every time it is opened. You pair it with a clipboard where you note the counter count, why you opened it and sign.

It can be picked, that can't be avoided. But the act of opening it creates a trail which can be detected. Adding a false clipboard entry is detected by subsequent users, there typically aren't many people with access.

Determining that you have a breach allows it to be investigated, mitigated. The lock is an important part of that, but it isn't perfectly secure so you manage that flaw.

Of course filing cabinets are getting rare and replaced by digital document stores, with their own auditing and issues.


I understand that being a fork of Snowplow is how you define yourself, but there's actually nothing on the webpage that provides any detail of what the product does, other than "event pipeline" right up the top.

I suggest putting at least some content on the website about what you do so that people can find you when looking for solutions in the industry, rather than having them adopt Snowplow and then splinter off later. I understand that your main focus is snowcatcloud.com which does have info putting some on opensnowcat.io will greatly enhance its discoverability.

Especially as the splinter strategy is going to become increasingly harder as people who care about open source won't adopt Snowplow to begin with, and people who don't care won't leave it.


Thank you! Agree! A section "What it is" and "What you can use it for" will be helpful to showcase when and why you would use it!.


Absolutely. The ability to search for these flags before a commit, during a review or release is so valuable.


The vanilla vim version is

    MANPAGER="vim +MANPAGER --not-a-term -"
Documentation can be found via :help manpager.vim


The .d directories make management via tools such as ansible much much easier.

You don't have weird file patching going on with the potential to mess things up in super creative ways if someone has applied a hand edit.

With .d directories you have a file, you drop in that file, you manage that file, if that file changes then you change it back.


I love that you can use validate: sshd -T -f %s To check if changes would break things.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: