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

I don't know how it is in other countries. We recently wondered what the right thing to do is and the Citystate of Berlin has an FAQ on recycling: https://www.bsr.de/die-top-13-mullmythen-26874.php which makes some things explicit:

(It is in German, but deepl translated the relevant section)

Do empty bottles and packaging have to be washed out?

No. Because the packaging is rinsed out in the recycling process, when the sorted plastics are shredded. It is only important that all packaging is emptied of residues [ed. The translation misses tmthat they mean large residue or levtover amounts], is not stacked and the lid is removed.


Where do you have this information from? The State of Berlin says otherwise https://service.berlin.de/dienstleistung/121864/en/ :

------ Sufficient knowledge of German You must have an adequate command of the German language (level B 1 of the Common European Framework of Reference for Languages).

If you were in possession of either a residence permit or a residence authorisation on 31/12/2004, you only have to demonstrate basic knowledge of the German language (level A 1) to be granted a permanent settlement permit. ------

In practice the staff giving interviewing you have leeway to assess your German level on the spot, but applying without demonstrated adequate German levels could lead to wasting ones time.


That's for non-EU citizens. There are 360MM non-German EU citizens - some of which are living in Berlin visa-free.


There has never been any language requirement for EU citizens to live in Germany or anywhere else, ever since freedom of movement was established.


Some? Wouldn't they all be visa free?

Yeah, that page is for non-EU-ians, because if you're from the EU, due to freedom of movement, you can live and work in any other EU country, and you don't even need to apply for a "permanent resident permit".


Well, most of these 360MM non-German EU citizens don't live in Berlin or Germany at all, only some of them do.


In Germany you have a probationary period of 6 months where both sides can give notice of 2 weeks without having to give a reason. The probationary period is really there to make sure that you fit the organization and that the organization fits you.

It is not usual that people don't make it through the probationary period, but it happens. If you know 5 months into a job that it is not for you and won't work out, then search for something that does. When asked why the time at X was so short, tell the hiring manager why. A place that dings you based on your honest assessment is not a place where you will want to work anyway.


Yes, when I first got to Germany I was surprised at this but after doing it once I loved it. As an employee I had no hard feelings about just saying something wasn't a good fit within a few months of joining (I have a slightly different but similar in practice setup with a French co currently that I'm leaving after a 3m trial period). I think that it's a good way to do things & I think I reflect the consensus view here that you absolutely shouldn't feel bad about leaving a dysfunctional company. The only exception is if you were brought in with the mandate to execute a turnaround, but it doesn't sound like that's the case nor that you have the authority to do so, so don't burn yourself out trying without the power to make real changes for probably not enough compensation for the hassle


You two are discussing this as if it's specific to Germany... is it really that rare? Every tech job I've ever had in the UK (admittedly not a huge sample size) has had some kind of probationary period baked into the contract, although the exact details vary (e.g. number of months considered probation, notice period while on probation.) Are there countries where this isn't a thing?


It's not as common in the US, since most states are at will, either side always can give notice at any time for any/no reason (other than targeting protected groups / whistleblowing, etc), there's not as much point to a probationary period.


> It's not as common in the US

But culturally many companies operate that way. It's easy to fire someone within the first ~6 months; if you've been somewhere for awhile, you give longer than 6 weeks notice; and if you've been somewhere for awhile, you get severance.


At many (well managed) US companies, there is a more formal HR process for dealing with poor performance, such as formal reviews, action plans, etc. that does not apply during the initial probationary period.


I think it's common across Europe (was the same with my Estonian and now French contract) but wasn't in the US because it's "at will" hiring in most states where they can fire you anytime... so why have a contract?


What's uncommon is the period after. Most employment contracts have a 4 weeks to 3 months notice period, both for the employer and the employee. This is very different from the US and Canada, where people give a 2 week notice.


Employees never have to give a reason to leave. The benefit of probation periods for employees who want to bail early is that the notice period is shorter (it is usually 1-3 months in most european countries). Of course, the downside is that the same applies to the employer and probation periods really are for the benefit of the employer since laying off an employee is an onerous prospect in most european countries.


I know a few people who bailed out just a month or two into the job. Their reasoning was simply that it wasn't what they expected (and they wouldn't have accepted the offer if they knew that while interviewing).

Doesn't really have to be any simpler than that, and for further interviews it does allow you to make those expectations clear if the question is asked.


Also keep in mind the flip-side of this is that if you leave before 6 months, some hiring managers will see it that you "failed" your probation and the previous employer took the easy way out to let you go for sub-par performance.

Obviously it depends on the politics of a situation, but be wary of those questions that might arise, and still leave on good terms if the new place wants to confirm you weren't let go.


If a hiring manager assumes this rather than asks, good for them, I wouldn't want to have to report to them anyway.


Just to add a bit of info: German businesses typically have a 3 month notice period in both directions (though I've seen 6 months). The probation period lets either you or the employer end the employment without a fuss.

This means that it's harder to get a loan or find an apartment until you're over that period. After that, you're golden.

https://allaboutberlin.com/guides/find-a-job-in-berlin#the-p...


The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups.

The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.


I have a backup, but this is not a solution. Only a crutch. I had those problems on several machines, including brand new ones.


Does one really need a jailed or chrooted instance when you can just create profiles?

firefox -P <profilename>


For that matter, Firefox has "open in new private window" as a built-in option on its right-click context menu for links.

Also I have a "work" container I use for this type of thing, so that's also an option in my context menu.


The profiles have a separate history, password store, settings and extensions as a bonus.


It doesn't anymore.

With GnuPG 2.1 listing of keys shows the fingerprint.


But for server installations (auto-signing, checking, etc.) you are often directed to GnuPG 1 because "less dependencies". Also "apt install gnupg" / "dnf install gnupg" both give you version 1 on the most recent Ubuntu/Fedora.

For desktop usage many prefer GnuPG 2.0, because they fear compatibility issues that the new 2.1 key storage format could have with 3rd party software, and you can't go back (at least this is the reason why the Homebrew maintainers still default to 2.0, but at least not to version 1 anymore since a few days).

So you have a mess of 3 stable versions, all used by many at the same time.


I don't know where people would run three versions at the same time. The information from the GnuPG project is clear: You can run GnuPG 1.x and GnuPG 2.x at the same time, but you should not have GnuPG 2.0 and GnuPG 2.1 installed at the same time, as bad things might happen.

What 3rd party software is using the keystorage mechanisms directly? Do you mean how information is output from GnuPG?

It sounds like the situation you are describing is the keystore, which has changed formats. GnuPG 2.1, as far as I can remember, will oll use the older versions keystore, but you are correct, once you have a 2.1 keystore it can't be used by GnuPG 2.0 and 1.x.

It's a tough call for the GnuPG developers and something distributions should help with. On one hand there is immense pressure to improve GnuPG, on the other hand, you have many actors who kick GnuPG around when it makes any deviation.

I would say defaulting to GnuPG 1.x is a bug and new releases of Linux, Homebrew, etc., should use GnuPG 2.0 at the very least, but better yet, use GnuPG 2.1 which has many of the things that people complain about fixed or in process of being fixed.


> I don't know where people would run three versions at the same time.

Not on the same machine, but server/automatic -> GnuPG 1, desktop 2.0 or 2.1. Also different people may run different versions, even GnuPG 1 on desktop because they are used to. This compatibility mess that seems to persist for while was what I meant why people prefer to use the lowest common denominator in their sigs/cards/slides -> evil32.

> What 3rd party software is using the keystorage mechanisms directly?

Aren't there any? Good, then I misunderstood that argument in the Homebrew debates I read, sorry. That leaves only the fear of automatic upgrading and the inability to downgrade again as a blocker.


In practice you can use all three versions of GnuPG on three different devices without a particular difference. One problem you might see is if you are using the newer experimental curve-based algorithms on a computer running GnuPG 1.4 and you get blocked, but you really ought not to do that anyway.

As for the downgrading issue:

It used to be you could just copy your .gnupg directory from computer to computer to computer and that's what constituted migrating your PGP keys.

This was also true for moving frmo GnuPG 1.4 to GnuPG 2.x. If you are starting with a new GnuPG keystore from 2.1 you can't just copy .gnupg and use it in a GnuPG 1.4 system, you have to export your public keys, your private keys, and your trustdb (although I am iffy on what this does) and import them on the systems where you are running GnuPG 1.4 or 2.0

I am unaware of any 3rd party software directly accessing the GnuPG keystore, but that doesn't say much.


Debian is currently switched to using gpg2 by default.


Debian is in the process of switching to using gpg2 by default.

Here's this week's LWN article about it:

https://lwn.net/SubscriberLink/696561/6392ebc623b794d8/

Note that it's a subscriber-generated link (articles <1wk old are paywalled). Please consider funding LWN's excellent work by becoming a subscriber: https://lwn.net/subscribe/


> For desktop usage many prefer GnuPG 2.0, because they fear compatibility issues that the new 2.1 key storage format could have with 3rd party software

Any idea what this will mean for Yubikey users? I've been wanting to set up my Yubikey 4 for GPG for a while, and have been... daunted.


It's insane that it ever defaulted to short IDs, the insecurity of which was not just known, but proven by demonstration, years before GnuPG was released.


If you use gnupg 2.0.x, you can set "keyid-format long" in your gpg.conf to get 64-bit key IDs (instead of the classic 32-bit ones). Not really good enough, but a reasonably effective short-term stop-gap measure. IMHO.


Worth noting for any Mac users, the version of gpg2 available by default in Homebrew is 2.0.30. If you want 2.1 you can install it from Homebrew/homebrew-versions/gpg21 at the risk of possibly breaking other formula that expect 2.0.


The go-to keyserver software is SKS https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home and the network of SKS Keyservers can be found at: https://sks-keyservers.net/

Things to know about keyservers such as SKS: There is no way to remove keys or a way to really delete information. Uploading to know server will propagate that information to all SKS servers in the network over time.


I don't really get what keybase.io is supposed to solve, but it doesn't get in the way of importing keys into Enigmail.

If you are in Enigmail's Keymanager you can import from a URL when the content is well-formatted.

Examples that work:

https://keybase.io/snassar/key.asc https://pgp.samirnassar.com http://keys.gnupg.net/pks/lookup?op=get&search=0x69A75542488...

It would be nice if Keybase made the URL more easily "gettable" instead of hiding it behind 2 clicks.


«I don't really get what keybase.io is supposed to solve»

Keybase was built to solve the "web of trust" bootstrap problem [1] by leveraging the web of social media profiles a user typically has with simple replicable proofs of social media identity.

[1] Arguably the hardest problem in PKI: how do you get user to trust that a public key is for the right person? In the classic PGP/GPG web of trust you do things like "key signing parties" and physical in real life interactions and deciding your threshold for how far you trust the friend of my friend signed this key. In the Keybase model you can see that the key (or family of keys) are tied to a certain combo of Twitter, Facebook, HN, et al accounts/profiles and generally trust that the person with all those accounts is the person you are trying to communicate with.


Fair enough, when it comes to coming up with creative ways to solve the web of trust problem.

I still do not know what problem keybase.io solves when they allow uploading of private keys.


That would be the second hardest problem in PKI: key escrow and key management. The answers to the questions most average users have like: What do I do if I lose my machine? If I'm logged in from the library or work or my friend's PC? If I use multiple machines every day?

When the "right" answer includes "Print out this long thing, put it in a safe deposit box, and pray you never have to type in this long string of numbers", you immediately lose a lot of potential users; it doesn't quite fit the "Grandparent test" (could your Grandparent use it?).

Absolutely there's a trade-off in trusting a 3rd Party key escrow, but there's an immense usability benefit to average users that want something easier to do and "some security" really can be better than "no security", even if a lot of hard-line paranoid wonks have good reason to believe otherwise.


My grandparents don't even use email. I don't think we should be setting them as the lowest common denominator for security. Some things that are worth doing require a little bit of effort.


You have have to consider the lowest common denominator in security. You're security it's only as good as your weakest link. Say you have an emergency and your grandparents need to email your PII to a hospital. Can they do it securely? You need to email some PII to them. Can you do it securely? Some security for all is better than no security for most, hence the "grandparent test".


I think it would be even better if we could design systems where it isn't even necessary for a family member to "email your PII" to anyone. That's a terrible idea in almost any situation, regardless of your security.


Keybase was created by NSA to make pgp/gpg harder...


I don't see what information Carla Schroder is adding to the ownCloud/Nextcloud split.


There are multiple ways of using Let's Encrypt that don't have to take the website down.


Yes which are more convoluted that the one liner to generate one automatically


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

Search: