I have been using ZFS for over two years, on any desktop that I control, as both root file system for FreeBSD setups and backup file system in many configurations. In almost all cases I don't have EEC ram and I don't need it really. Your comment is either outdated or wrong, ZFS is THE go-to filesystem on desktop for me.
Edit: oh and it works beautifully with single disk setups too.
Does anyone have any pointers to a resource for single disk ZFS setups? Last time I looked, most search results were entry points into a persistent flame war.
Wait until you get a 1-bit flip in a spacemap record.
Then you just won't be able to import your pool (insta-panic). And good luck with fining and fixing that flipped bit.
Maybe so. In my experience 'helping' in most cases sides with other time/nerves wasting exercises - like browsing twitter in other form. Role playing, not actual real thing.
Getting better in what I do (whatever that is) first (so focusing on what I do), then helping as a side effect, that's possible.
Being politically correct vs getting the job done, I'll always choose getting the job done. There is plenty or role playing projects where your feeling matter more than your skills. In last couple of jobs I am always asking about company policy, if they start piling about diversity and getting everybody heard and how everybody's feelings are most important thing, I don't want to work there.
Earn your place with your quality and your skills, not with the help of inventing newer and newer rules until nobody can say how crappy, sub average and difficult to work with you are.
(Talking to a random programmer with no skills but huge area of possible butt-hurt).
Edit: btw can't agree more with Stallman if that's not clear from my post. Love that guy.
> Being politically correct vs getting the job done, I'll always choose getting the job done.
I am absolutely baffled at the idea that there is ever a situation where getting the job done requires a choice to be politically incorrect as implied here. Do you have an example of the phenomenon you're discussing?
Yeah, like mirko said, being pressured by project leader to merge absolute crap (I was in charge of merging), "because it works and we don't want to suppress less skilled colleagues". "Try to explain nicely how to do it better" while that other guy a) doesn't want to learn and b) has feelings that are more important that making better software / learning.
Edit: to clarify, that other guy couldn't understand the project or how to do proper code so all the PC dance afterwards is the perfect shield and role playing. I just walked away after few weeks.
Hey, I don’t know your situation so this may be nonsense, but what you describe doesn’t sound so PC.
The guy’s code worked? Doesn’t sound unreasonable that the project leader would want it merged. Put the technical debt on the backlog, get on with writing other code that works.
The project leader presumably had a team to manage. Seems perfectly understandable that they would want all their team contributing, even if some team members were vastly more productive than others. The alternative is over-reliance on key personnel, or back to the recruitment treadmill (both of these are risks and uncertainties - which it’s the PM’s job to manage down).
The project leader should want his less skilled employees to grow their skills so that he may one day have a greater breadth and depth of talent at his disposal. It might even be reasonable for the leader to want his most talented developers to do nothing but coach junior colleagues - particularly on a typical project that isn’t rocket science, where 5 average developers will be more useful than one rockstar.
Like I said, I don’t know your situation. My point is that the behaviour you describe seems like it could be quite normal and rational and not motivated by PCness at all.
A low-quality codebase slows down everybody on the team and causes tasks that ought to be routine to hit unexpected roadblocks. Every software team has some set of practices for maintaining and improving the quality of their codebase; a few teams, like ØMQ, merge any old crap and then fix the crap (_but not in the backlog_, dear God! _Right away_, before it costs somebody else debugging time) while most teams require that patches meet some kind of quality standards in order to be merged.
By far the fastest I've leveled up my programming skills has been when better programmers looked at my code and told me what was bad about it and what could be improved. You're commenting on the story of someone who offered such commentary and had it rejected.
Word by word this is exactly my experience. Code I was forced to merge was working only on that day in a very limited set of tests. That's not 'working' in my definition. First next feature we needed to add and code would break all over the place. First I was politely telling it can't work because of this and that, then I was fixing the code silently so we don't all hit the roadblock the next day, then I was trying to discuss that we can't really work that way, then I walked away. All in a span of 30 days.
A shaky patch that “just works” but doesn’t have good tests is a time bomb waiting to happen. When a change six months later breaks the shaky patch, who fixes it?
Piling on lots of little bad changes is only possible if you have a good cleanup process (that I’ve never seen, who likes cleaning up bad code that isn’t breaking yet).
I think this may just be different management / development philosophies.
For example not calling a problem in the code “a problem” but “possible place for improvement” as to do so might lead people to think their code is “problematic”... then i resigned...
I’m unsure if this is the sort of politics that’s the context of the article in question. For clarity, the article in question spawned off of an email thread regarding calling women by nicknames in a condescending manner without their consent.
Yes, within context of the article, and the ambiguous language of the poster, I'm questioning an example in which politics in context of the article applies to the experiences of the claim in question. The claim in question then refers to an example which does not apply to the context of the article. I remain fairly confused.
Let me explain further then. It is all tied in, across the spectrum, along with linux code of conduct and sqlite topic today. In 'normal' company I can either respect the rules or walk away, there is usually little room for changing them. In open source project, small number of vocal butt hurts or political opponents that can use and channel 'hurt ones' can do much harm to the project, because they 'can' enforce different rules by being very noisy.
In this particular case, same with Linux CoC, reasons to try to apply or change rules can have much more sinister motives than what it seems on the surface.
Case in point.
1. Initial linux CoC is introduced by Greg KH, after one sensitive 'programmer' got hurt by Linus general behavior. Oh also she was working closely with Greg if I am not mistaken. https://lkml.org/lkml/2013/7/15/374
2. Next Linux leaves the project (temporarily? fingers crossed) and Greg KH remains to be the top decision maker for what goes in into kernel. Same guy who wanted to push d-bus like his life depends on it, which doesn't show good judgment for the project well being.
3. Greg KH suggests updating the CoC. It is signed off by Chris Mason, Dan Williams, Greg KH, Jon Corbet, Olof Johansson, and Steven Rostedt, not to mention Linus himself. Rik van Riel, Tim Bird and Ted Ts'o make endorsing comments on the LKML in ensuing discussion. That is, the change is supported by Linus and at least 9/10 TAB members. HPA made no comments
4. Linus goes on leave
5. Greg KH and Olof and another guy make some minor wording changes to the CoC, and adds a new page describing how the kernel maintainers interpret the CoC, most of this would best be described as watering down some of the more objectionable parts of the unedited CoC. It is reviewed by Steve Rostdet and Ack'd by Linus, Ted Ts'o, Rik, Corbet, and approximately 50 other people.
Then of course, Ted Ts'o (the same Ts'o mind you, who people bring up as the person Sarah Sharp supposedly weaponized the old CoC against, so if anyone, he'd have a bone to pick against CoCs) clarified[1] that the addition of a CoC was a directive from linus, not something Greg snuck in, and while shepherded by Greg, was done with 'a huge amount of consultation with the top contributors to the kernel'.
So basically, if one actually looks at what really happened, instead of what what one wants to believe(?) happened, all of the sinister motives disappear.
I once felt the same way, that there’s always a good way to give criticism. The shit sandwich really works well in even the mist dire situations (“this is great,” “this is garbage,” “but this is great too”).
But I once had a co-worker who had an opposing development philosophy. It was in a bit of a weird, anarchic environment where there was little supervision, but steady budgets.
There was an algorithm made and after reviewing it, it was just really, really bad. It was for improving health, but it used the wrong population, it inferred from data inappropriately, it made broad recommendations, and it did so I consistently. It was garbage, but it’s not helpful to say that as that never really helps and is not constructive and not accurate. Basically what you’re saying.
I got the merge request and sent it back with a thoughtful commentary, adding in another peer for input, asking for test cases, asking for user story requests, etc. Pretty polite.
They resubmitted it unchanged saying “no, I know it’s right. Just take it and we’ll fix it later.” (There’s no we, it’s just this one person).
I spent more time and sent more detail, showing similar, valid changes.
Same thing back. I spent probably a few hours between the two responses and they were resubmitted within seconds.
I figured I’d chat with the person so based on work schedules sent an invite for two days away.
Person said they couldn’t wait, had to go now. I tagged the other two maintainers, one was on the initial reply, and asked for a review. They pointed to response #1 and said “no, refer to reasons.”
Submitted then went to boss land and asked boss to approve the merge. Boss can’t do that, etc etc.
Boss and I meet with submitter. Submitter asks us to read original submission and gives nothing further.
Boss asks me to reconsider, I point out comments for improvements, submitter says they won’t change them. So request stays at no.
Lots of HR madness takes place over the next few weeks. Merge request never made it.
I probably spent 40 hours, plus peers and submitter added on.
Obviously, I’m not skilled enough to communicate why the merge request wasn’t sufficient. I’d love to learn, and am always trying. But I sometimes wonder that I could have saved a lot of time by just saying “this request is a garbage fire and a waste of time to discuss further. You are unworthy.”
It wouldn’t have worked to make the submission good, but would have cut directly to HR and skilled all the well intentioned attempts that ate up time. If this were OSS, it might be good for the community to prevent future stupid stuff.
I’m not sure what the solution is as you have folks who are good in one thing (algorithm design), but bad in another thing (conflict resolution / mentoring randos). Hopefully you’re lucky and have leads with both skills.
All of this stuff is in service of getting the job done. If people can't usefully collaborate with other people because they literally never developed adult social skills (not uncommon in the tech world), then they're not going to be good contributors or collaborators. They won't know how to constructively criticize others, or take constructive criticism, they won't learn from their mistakes, and they might not even learn the right lessons from others' mistakes. The organization as a whole suffers, which is a lot worse than any individual not getting what they want.
One "adult social skill" that comes to mind is the ability to deal with people who haven't developed adult social skills. The vast majority of people in my own professional environment seem to do this even instinctively.
I totally agree. But at the same time, immaturity doesn't let anyone off the hook for being shitty to other people. It's not just on the Internet- it doesn't let them off the hook in real life either. The post I responded to was from someone who said they were so pissed off that people were telling them not to be shitty to other people, that they left the job a couple weeks later.
The Internet's a different beast- it's often an ignorance-not-malice situation when ugly things happen in places like open source project mailing lists. Electronic communication is notorious for not conveying nuance or irony or sarcasm. A CoC (in principle) seems like nothing more than an explicit statement intended to curtail ignorance that could be misinterpreted as malice, which in turn could derail a project.
I agree with that list of priorities, but I don't know what you mean by "feelings"- I wouldn't use that word in my own division of goals. I would just call it "effective communication", not "feelings". You're phrasing it as if the the scenario people are trying to avoid is some brutally honest truthteller vs. some hypersensitive weenie who can't handle the truth, and that people are claiming that it's more important, in that situation, to preserve the weenie's feelings than it is for truth to be expressed. That's not the intention of CoC's or workplace etiquette or professionalism.
Think of that truthteller vs. weenie scenario: in cases where one person is potentially hurting someone else's feefees over professional criticism, there is for sure some subset of those cases where that's exactly what's happening. One person is 100% correct, and is being brutally honest with someone else who is both incompetent and hypersensitive, and deserves that brutally honest criticism because that's the only way to get through to them.
That's a subset of those situations. I don't know how much of a subset- 25%? 50%? My gut says more like 1-5%, but my gut is naturally biased (like everyone's). But in 100% of those situations, I guarantee that the brutally honest truthteller THINKS that's what the situation is. In my experience, the brutally honest truthteller is expressing their own confidence in themselves far more often than they're expressing an objective measure of cold hard truth. Some subset of them are expressing cold hard truth that can't be ignored, but all of them think they are. If they had really truly done their homework and knew what they were talking about, they would have eventually learned humility and skepticism, and would be much less likely to jump into the brutally honest truthteller role in the first place.
Simple example of productive etiquette: when criticizing someone's work, it's generally much more effective to phrase it in such a way that it doesn't come off like a personal attack. Meaning, some variant of "this code is bad" works better than some variant of "your code is bad". In the latter case, natural and common cognitive biases (i.e., human nature) are such that people will almost always feel at least a little bit defensive, and are more likely to reject the rational aspects of the criticism because they sense that the other person is criticizing their work for personal rather than rational reasons. I'm totally aware of these biases in myself and I'm still almost as susceptible to them as anyone. It makes it easy to brush off the criticism as coming from an irrational place, on a subconscious level that never even rises into the conscious mind. Making it personal diminishes the credibility of the criticizer in the eyes of the criticized.
So, as a rule, I have found that it's much more effective to make an effort to phrase things as objective criticisms rather than personal attacks. This isn't tiptoeing around someone's feefees, it's literally just making an effort to communicate in a way that is most likely to produce a positive outcome (in terms of production, not feefees- the preserved feefees are just a pleasant side effect). In my experience, that's all that most CoC's or calls for workplace civility or whatever are advocating. Some people are used to working in large organizations full of big egos and unbalanced people from all over the world. Other people have spent their professional lives in much smaller bubbles, and never had cause to think about any of this stuff. But successful open source projects resemble the former much more than the latter, and can require similar social awareness to keep things running smoothly. Things like CoC's, ideally, just make sure that everyone's on the same page in as harmless and nonintrusive way as possible. I'm sure they've been misused or poorly implemented in specific situations, but in principle it all seems eminently reasonable to me.
I’m not OP, but I don’t think you need to convince anyone of your position.
This is not a problem that requires resolution in order to succeed. Different people have different ideas and philosophies. Build software with a group that’s compatible.
Done. Problem solved. There’s enough cool projects that if you disagree over something that one side of the argument thinks is trivial then you don’t have to stay married for the kids. (Or even get married in the first place)
It seems like a Jainist marrying a Baptist and then trying to really convince the Baptist to go veggie. It’s a big deal to the Jainist, part of their core beliefs, really important. The Baptist doesn’t care. Only cares because they’re married.
Now imagine it’s a stranger on the street that the Jainist is attracted to and goes into “quit meat so we can date.” The stranger is likely going to not respond. Eating meat is not an issue for the stranger, even though the Jainist thinks it’s really important (and millions of other Jainists do as well).
PS- Jainists are cool, and while I don’t know all Jains, I’m pretty familiar and never met one with such an unreasonable approach.
We agree completely assuming that the other less skilled programmer doesn't twist any code criticism into personal attack and that project leader cares more about project quality than about feelings.
When I review or comment the code I couldn't care less if you have three hands and a hump, in fact I am least gentle about my own code. When every dialog goes like Me:"This code is bad" -> Other guy:"Why are you attacking me" there is little room for staying completely politically correct.
I was actually suggested never to use 'this code is bad' in any form in the last place I worked, because that can scare away less skilled colleagues.
“then they're not going to be good contributors or collaborators.”
Maybe you mean aren’t optimal contributors or collaborators. There are obviously good contributors who lack what some think are adult social skills. I mean, you can look at Linux and see commits with “poor social skills” that do quite well.
Oh there is third option too. See my other post, I walked away while precious little programmer that has no skills but has feelings remained working at that company.
> False choice; there is absolutely no reason whatsoever that one would ever need to choose between being polite to others and getting the job done.
It is very disturbing for me to see Greg KH being at the top and deciding what goes into Linux. There is history of agenda that doesn't align best with kernel user interests. Can't forget d-bus events very related to this person. I did switch to FreeBSD couple of years ago but I love linux and it is not easiest to observe all the latest events.
Greg KH already decides what goes into the "stable" Linux series (4.y.z, for instance 4.18.15), which is what most people actually use. Besides, he assumed after the 4.19 merge window, and he's handed the 4.20 merge window back to Linus; it's in the merge window that new features come in (after the merge window closes it's mostly only bugfixes), so it's still Linus who gets to decide.
Is stable different from latest? I am not sure how much independent decision space he has, otherwise we would have d-bus in stable long time ago. Maybe I don't know the process well enough but I would be surprised that Greg can merge something that isn't approved in latest.
Fingers crossed it is only 4.19, I am kind of seeing this as a bigger event but I may be wrong.
Yes, I am aware of that but are LTS kernels in any for different from the mainline kernel? Can LTS kernel contain code that is not approved and tested in mainline first? They are 'older' but they contain same feature set that is already approved by Linus, right?
Edit: oh and it works beautifully with single disk setups too.