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

Sorry what? Yes, they do. Second-hand knowledge, though.

No, the requirement is that the job is for a speciality occupation and that the H1B be paid the prevailing wage for that job, not that there was an attempt to hire locally first.

For an I-140 PERM (employment based green card) however the requirement is that there was an effort made to hire locally first.

Most people on HN are uninformed about this, well actually uninformed in general.


The jobs filled via H-1B are not “specialty” positions, everyone knows this. I know that’s what the visa is ostensibly supposed to be used for, but it’s a very silly thing to pretend at this stage. I agree that many are uninformed on this, and my friends who don’t work in tech think someone on an H-1B visa is like a “particle physics PhD” or something, and not “database administrator” or “backend engineer”.

Ah, that was it then. The person in question was probably filing for that instead of trying to get another H1B. Thank you for clarifying!

There are two cases: I am uninstalling because I never want to use the app, or I am uninstalling because I know I currently don't need the app and will reinstall after 6 months when I do.

An example of first is a trial of an app but you don't like it in the end, an example of the latter is a game that you might want to play with the same settings later.

Now, I want the option. In the first case I don't want these inert files taking up disk space and in the second I want to have those files.


I stopped trying new apps as often, because I don't like how I can never really go back to a state before it was installed, unless the developer actually put effort into not spraying files everything and not leaving a trace once gone. I appreciate these developers very much, and am more likely to keep using their apps. The most junk an app install puts on my system, the more likely I am to want it gone.

We can remember it for you, wholesale.

So... it's actually a reasonable objection over bzip2? I mean, you explained why it does not work with bzip2.

I think their argument is sound and it makes using bzip2 less useful in certain situations. I was once saved in resolving a problem we had when I figured out that concatening gzipped files just works out of the box. If not, it would have meant a bit more code, lots of additional testing, etc.


totally agree with the statement though i feel its not an objection over bzip 2 rather than how it was implemented in programs that apply it. but i'm not really 100% since admittedly i did not personally reverse engineer bzip capable programs to see the current state of afairs. I am simply going by descriptions posted in comments and general system knowlesge.

how to compress data has little to no relation to how this compression can be implemented in programs. How its implemented, will reflect on how the quality of the algorithm is perceived, becaus e the two are not seperate from a user perspective.


Indeed, they are two separate concepts.

I write lots of automated tests, but almost always after the development is finished. The only exception is when reproducing a bug, where I first write the test that reproduces it, then I fix the code.

TDD is about developing tests first then writing the code to make the tests pass. I know several people who gave it an honest try but gave up a few months later. They do advocate everyone should try the approach, though, simply because it will make you write production code that's easier to test later on.


... hmm, just looked it up. According to some sites on the web, TDD was created by Kent Beck as apart of Extreme Programming in the 90's and automated testing is a big part of TDD. Having lived through that era, thinking back, would say that TDD did help to popularize automated testing. It made us realize that focusing a ton on writing tests had a lot of benefits (and yeah, most of us didn't do the test first development part).

But this is kind of splitting hairs on what TDD is, not too important.


I don't agree with this. In my view, there are plenty of cases where the product changes are shoved down our throats.

I think the problem is that the product folks don't actually listen to the market. They read Jobs' biography and are convinced that they will tell their users what product they will like and that they will see the light later on.

The sad reality is: they are not Jobs (and even he was not faultless). So, we get Mac like Windows interfaces, we get mail clients losing features, we get AI in every single app you see, etc.

Just my 2c.


Why do you buy things you don’t like?

And if you’re convinced that most people don’t like most products… why don’t you make a fortune building what people actually want?


> Why do you buy things you don’t like?

In my case, because it's the only option in some situations.

For eg, I wanted a phone that has an unlockable bootloader and a decent/Qualcomm CPU.

I'm immediately down to Motorola and OnePlus.

If I want future proof performance, I'm down to the OP 15 only.

Yes, I have RSI today, but with any luck that can go away. However, a Vivo will not get a BL unlock tomorrow magically.


Funny story: I once bought and started up Galactic Civilizations 3.

It looked horrible, the textures just wouldn't load no matter what I tried. Finally, on a forum, some other user, presumably also from Europe, noted that you have to use decimal point as a decimal separator (my locale uses a comma). And that solved the problem.


In my experience, companies are perfectly happy with US companies, as long as the data doesn't leave Europe. This means we have to prove we only store data in European datacenters.

I guess that's fine for now, but it would be better if we could get European alternatives to AWS or GCP.


There are lots of alternatives in Europe, just a little different, and smaller than the big 3

> companies are perfectly happy with US companies, as long as the data doesn't leave Europe

I think it's pretty clear they can not guarantee that, see the CLOUD act.

Also, they could shut you out or turn your whole business off if you, or your country, offends the orange fuckhead


And why wouldn't this European equivalent do something that a lot of people in Europe dislike too, in the future? The entire model of large cloud companies is bad.


That's a different risk profile. Companies are governed by local laws, usually, and currently, that works here in Europe.


USA companies are subject to us laws, so any data will never be safe. Companies can be gagged, forced to seal their customer data and forced to lie about it, by law !


I'm not sure if it's accurate, but according to the summary on Wikipedia at least, the law "provides mechanisms for the companies or the courts to reject or challenge these if they believe the request violates the privacy rights of the foreign country the data is stored in."[0]

If that's accurate, your country's privacy laws would supersede US law. That said, as things are going, it's unlikely that they do.

[0] https://en.wikipedia.org/wiki/CLOUD_Act


I think that's different because refactoring usually involves calling the same functions/methods albeit in a bit more readable way.

When not given a clear guideline to "just" refactor, I have had problems with LLMs hallucinating functions that don't exist.


I guess that's why nobody reads it. /s


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

Search: