1,272 karma · joined September 23, 2018
If people die because they engage in non-violent activism it's just wrong, plain and simple, there's no gray area (at least I have a very hard time thinking of one). The overall number of activists or the growth thereof has absolutely nothing to do with that.
If a state agent wants my data and brings the necessary paperwork to get it - I'm not expecting anyone to put up a hopeless fight for me, or at least not for the 100 bucks or so that I'm paying yearly for PM.
I just expect them to not sell out my data altogether, which PM doesn't seem to be doing, and this is all (or at least, most) that I care about.
TeamSpeak didn't bother to acknowledge that a lot of people often just want to write some messages to others without actually hopping into a channel/server, let alone a VoIP-channel. Their synchronous-only communication philosophy via community-maintained servers just didn't pan out.
Yeah but the Taliban (or the the Afghanis in general, for that matter) didn't attack anyone.
A bunch of radicals made 9/11 happen, and as it happens, the main guy behind it happened to be in Afghanistan and on somewhat okay-ish terms with the Taliban, but the Taliban themselves were perfectly okay to negotiate his extradition if my understanding is correct. That is, they were, until the first bombs started to drop.
For all I care, Afghanistan was a bloody revenge war, nothing but catharsis for the bruised American soul. It was never about the women or democracy or the well-being of the Afghanis in general, because if that was the case, the US might as well have started with Saudi Arabia (which had probably more to do with al Qaeda than Afghanistan to begin with). In my opinion, it wasn't even about OBL, because otherwise the US would've taken the Pakistani coddling with extremists (and ultimately the sheltering thereof) more serious than they did.
Anyway, I'm already ranting again... I just sometimes wish everyone on this planet was a bit more naive, you know, and just believed in the general good of the people. Yes, there are always a few crazy outliers, yes, there are always those who try to gain advantage and power by manipulating the masses by abusing their fear and primal instincts, but in general, most human beings just want to live a peaceful live, not having to worry about drones and bombs and stray bullets and whatnot. And by believing all together in this common good, I think the world might just be a little bit a better place. At least in my pipe dreams...
As someone with a slightly pacifist streak and a very strong dislike of the military industrial complex, this statement, as obvious as it is, somehow still makes me furious...
I often wonder how people working in these circles or supporting politics in this direction sleep at night. It's so obviously pointless, so obviously destructive, so obviously detrimental to humanity as a whole... I don't know. Maybe I'm just too naive, but I just can't decide if I should feel sad or angry about it.
(sorry for the somewhat unrelated rant)
I probably wouldn't care about it too much if they didn't mess up the rest of their apps into the dogturd that they currently are. Doing bad UX is one thing, making UX consistently worse with pretty much every update another. And that's what Spotify has been doing for years now - if I could go back to a client-version from a few years ago, I would, immediately, without thinking twice.
The fun part? My company jumped on the SAFe-train a while ago, and Spotify was heralded as the "prime example" of where agile and all that works out really well.
I have no idea what they are doing, but whatever it is - if they continue like this, I'll go back to pirating music, because they're getting really close to having just-as-bad of an experience as that. And I really don't mind paying 20 bucks for my family account; experience is all I care about.
But when the Saudis presumably financed some of the same/similar bad guys it wasn't even worth much of an investigation? I find such "they're bad guys!"-arguments to be applied very inconsistently
The Germans might see that a bit different than us ;) Jokes aside, the article was of course in German.
According to the statement, the student tried "to force his re-acceptance to the phd-program with legal and political means".
To be honest, I'm not quite sure what to make out of the whole situation (as a Swiss, originally from the area of St. Gallen, where the school is).
I would be heavily surprised if the HSG would let itself pressure to the effects that the headline of the article insinuates. The school has a bit of a reputation in engineering circles as "useless MBA graduates factory", but being beholden to Chinese interests? That seems quite the stretch to me.
I think it's also a bit a question of team size. If your project has just a handful of devs working on it, merge-commits really don't matter all that much. If there are a few dozen with a good amount of juniors on the repo (a bit over 40 devs in my case), the commit-history becomes an absolutely unreadable spiderweb, that's at least my experience.
At work, we want to move towards trunk-based development (merge to master goes straight to prod), but whenever master was broken, a look at the commit-history didn't really all tell you that much about the who, how and why without checking it out and digging into it. So we've recently started to enforce linear history, in which case it is immediately obvious without the shred of a doubt who's responsible. Analyzing the build became an absolute breeze, at the cost of having a bit of a harder time at "insertion"-point (which is perfectly fine, given the fact that after merge, it should eventually go straight to prod).
It took a while to get everyone on board, but it was really worth the efforts and can only recommend it (I most definitely will prefer a workplace that is open to such practices in the future). In general, most devs were also quite happy to be guided through the process, as it is clear that git is probably one of the longer-lasting constants in our industry.
Also, I can't repeat it enough; speaking from experience, most devs severely overestimate the complexity of cherry-pick/rebase/reset/reflog etc. Whenever I had sessions explaining it or helping someone out with a problem, they had their first "aha!"-moments after a few minutes, and after that with some do-it-yourself-experience most of them get there rather fast. Obviously, there are always a few outliers who need a little bit of extra-nudging and extra-help to stay in line, but those are usually the ones who often also need that sort of assistance in other areas so that's okay.
I think you're referring to what I call "conflict cascades"? E.g., you're 4 commits ahead of "master", and want to rebase on top of it - but you have a conflict with your first commit, and after you resolve it, this results in conflicts in the second one, etc.?
It's a very interesting question because it's one of the main pain points of rebase that simply does not exist with merge.
What I've found for myself is that it's very important to create "atomic commits", which do not rely on other commits to make sense or "be complete". For example, a very common thing that I see is "fix formatting", "fix tests" commits, because some build was complaining about something being broken. And it's often these kind of commits that create weird conflicts (especially the formatting ones) because just a lot of code is moved/refactored/added/removed etc.
But do these commits make sense on their own? For example, if you have a history as follows:
<commit-1> Introduce new fancy feature
<commit-2> Fix formatting
<commit-3> Fix tests
This was of course just an example, but in my experience, if people follow these kinds of trains of thoughts - what can be in a separate commit, what should be together, etc., there is an inherently smaller conflict-cascade-potential, which pays off a lot when rebasing. On top of that, it also makes history generally more readable and individual commits more meaningful and easier to cherry-pick.
I was not :P But the commenter also said in the linked comment that they "understand how git works", so I took the liberty to make a few assumptions ;)
> But the fact that GIT imposes its internal data model on you
It does, to some degree, but once you get a grip of "everyday commands" that go beyond commit/merge (cherry-pick, rebase, reset, reflog), it's actually almost surprising how little you have to know about gits internals. It does help to have an idea about them, though.
My main complaint about git is that most commands have too many options that make it do too many different things. And that resolving conflicts via command line is absolutely atrocious (something I actively avoid and discourage).
> I know that one day I'll get completely sick of GIT and will research and learn it to the bone
I can only recommend it! It's really not that hard as many people suspect (as I've mentioned, I have a bit of a habit of teaching people git at work). If you had any exposure to something computer science in the past, the puzzle pieces probably start to come together after some hours.
And it's probably one of the longer-lasting constants in our industry, so in my opinion, it's really worth it to know how to make good use of it.
Regarding the second point - if you have a rebase-based work-flow, you will encounter this problem less often (or not at all).
For your third point - what helped me a lot is to actively distinguish between commits and the working tree, and making myself aware that branches really are just "pointers" to commits (obviously, but somehow, actively thinking about it made the intent of git commands a lot easier to understand). Also, most git commands are just combinations of other commands. git reset is just moving the pointer (--soft without touching the working tree, --hard will do so), rebase is essentially a hard-reset with consecutive cherry-picks afterwards, and so on.
Also, an eye opener for me personally has been that e.g. an interactive rebase with squash towards a branch that is strictly ahead of you except for the commits you want to rebase is essentially just a "git reset --soft <target>", and then recommitting everything with a fancy commit-message. This and similar mental gymnastics with git-commands has helped me a lot; most of them really are quite sane (except for all those crazy options), "git checkout" is really the odd-one-out of the bunch (and "git pull" a combination of things that should never have been combined in the first place).
I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think OP was referring to this cluelessness with 'not using properly', rather than which approach to git is the best.
I work on a monorepo with 40-something other devs, and we've recently switched to enforced linear history because the history got to the point of being completely useless, it was an unreadable spiderweb. The problem was not that folks didn't see that what they were doing was not-so-good (introducing often more merge-commits with every PR than non-merges), it was that they had no clue how to avoid that.
It took us quite a bit of time to get everyone up to speed but pretty much everyone got around to it after a while. It's not rocket science after all.
Technically not an identification, but Zero-Knowledge-Proofs might be the solution to that. If I remember correctly, some countries in the EU are looking into this for medical prescriptions - proving your eligibility while exposing zero information about you.
That being said, we should really take these anecdotes with the appropriate grain of salt. After all, we're here in a thread about countless companies being threatened by security flaws. A dev that "gets things done" (from a business point of view) might actually do that, but do they also think about all those other requirements that business themselves can neither validate nor appreciate if measured by short-term KPIs?
I'm not saying that's happening, but I've seen too many "Why are you spending weeks on this, I can do this in half a day!"-kind-of-devs, that then hack something together that technically works as the requirements demanded, but completely falls flat under any aspects of maintainability and extensibility, let alone security.
Yes yes. And this was of course very maintainable, up to todays standards, easy to onboard new hires in, not falling apart in edge cases that weren't part of the demo, code that was audited by multiple developers, it didn't make any shortcuts in terms of security, etc. etc. etc.
That some business guys are amazed by the "lone wolf dev skills" might be explainable, but on HN we should know better. Yes, there are devs that get a ton done irrelevant of framework, but "getting things done" (in terms of business requirements) is only part of the story.
I see where you're coming from, but I'd like to add a counter-argument to that. I'm currently working on a (mono-) repository with 40-something devs working on it, and we've recently switched from a "everything goes"-commit-history-approach to enforced linear history (while only a handful of people are allowed to directly commit on main-lines without a pull request).
The main reasoning was this: It became almost impossible to understand why a build broke on the mainline by just looking at the commit-history itself. It was always needed to go through build-logs and such to get the picture of the how and why, and often even to get to the 'who', because the commit-history itself was just riddled with merge-commits. For the few devs who took care of that, this was a huge issue, while everyone else was just happily committing away.
So going to the linear-history-approach made "analyze, understand" a breeze, but made "insertion" harder. We had to put in quite a bit of effort to get everyone up to speed (rebase, squash, reset, cherry-pick etc.) and set up some tooling for basic sanity-checks (pre-push-hooks etc.), but it was well-worth it, and a lot of devs were actually happy to be guided through this because for them it's clear that this will also be useful further down the road (in other jobs), not just for the current task at hand.
And at last: It's really not that big of a deal. Just before opening a pull-request (or whatever your equivalent is), have a look through your change-set, run a bunch of commands if necessary, and done. Once you get the hang of it, it's pretty straight forward. It might not be worth it for you personally, but if you work on a repository with many other devs, there might be others who are grateful for that.
It obviously needs a bit of critical thinking when reading it and taking everything with a grain of salt, but that's something I really hope we can expect people on HN to be capable of?
I feel like you just described email (or rather, "the" email spec, as if there was a single one) in general.
Yes it obviously still serves its purpose but what consists a valid email-address (let alone email) is specified in such a godawful way that every application that I've seen in the wild trying to address this problem somehow fails at it (sometimes in negligible, often in very gross ways).
If devs all over the world manage to screw it up over and over again, maybe it's just time to call it quits and acknowledge that the spec is broken?
And it's time well-spent in my opinion; git will probably be one of the longer-lasting constants in software development.
Those guys are still sending commits (patches) to each other by mail, I think they willingly live in such a special and weird bubble that it just can't be compared to any "real life industry project".
We've recently started to enforce linear history on our main branches at work, because it makes analyzing broken builds such a breeze. The mantra is "Insertion is hard, analyzing/understanding is easy" (for a merge-based history, it's pretty much the other way around), and so far it's quite the success.
It did take quite a bit of effort though to get everyone up to speed, and it still requires the occasional help to clean up the commit history of some merge request, but it was well-worth the trouble so far.
In my opinion it works quite nicely. The 80-20-split for gymnasium (which requires an entry-exam, but again, region-dependant) ensures a certain level for students in gymnasium, and the "job schools" for the apprenticeships allow for job-specific education. All in all, I consider it a pretty decent system.
Anand Giridharadas addresses this in his infamous google-talk quite nicely I think: https://www.youtube.com/watch?v=d_zt3kGW1NM&t=623s (I'm linking this talk on HN way too often, but it just seems perfectly fitting so very often)
Their UI was somewhat lackluster but they recently released a completely overhauled version (just a few days ago), which seems kinda nice so far.
All in all, I can only recommend it. That being said, I'm mostly only receiving mail and rarely ever sending out any, so YMMV.
The same motivation that drives some folks to study e.g. philosophy, even though it's perfectly well known that this will never make you rich: Because they like it.
You don't just e.g. found a company for the sake of money - you also do it because it allows you to do things on your own terms, it gives you prestige, it gives you the satisfaction of being 'successful'. In todays day and age, this is usually equivalent with 'generating wealth', but I'm a firm believer that this does not necessarily have to be the case.