TV;DW: through the last few centuries of the history of western fashion, women's #pockets were HUGE (even during the periods when the fashionable siluette was slimmer).
YouTube: Women's Pockets Weren't Always a Complete Disgrace | A Brief History: England, 15th c - 21st c (Bernadette Banner)
Charles Stanhope likes this.
Elena ``of Valhalla'' reshared this.
If you're annoyed by the shit #Signal is doing, don't switch to the next centralized thing. They all tend to go bad after a while and you can't do anything about it. Use decentralized messengers instead, like #XMPP, #Matrix or #Deltachat. Federated protocols like them can't add features unless a lot of people agree.
3 people reshared this
Even if you put ecological destruction and so on aside, it makes the target on their back bigger. Payment service providers are regulated in a lot of countries. The regulators in the EU will probably want to know who sends money to whom. Itโs a good excuse to block and/or raid signal.
@unsuspicious
@unsuspicious
Bevilacqua Gustavino reshared this.
Dear fediverse: do you know of any online shop in Europe that sells food-grade paper packaging such as bread bags in quantities suitable for the needs of a household (a min quantity of 100 pieces is fine, 1000 is not, 10000 is definitely way too high)?
Excluding amazon / ebay / other big platforms.
Thanks, and boosts welcome
Gentil fediverso: qualcuno conosce dei negozi online in Europa che vendono imballaggi di carta per alimenti, tipo i sacchetti del pane, e che vendano a privati in quantitร adeguate a privati (acquisto minimo 100 pezzi va bene, 1000 no, 10000 รจ decisamente troppo)?
Che non siano amazon / ebay / altre megapiattaforme.
Grazie, e i boost sono graditi
Excluding amazon / ebay / other big platforms.
Thanks, and boosts welcome
Gentil fediverso: qualcuno conosce dei negozi online in Europa che vendono imballaggi di carta per alimenti, tipo i sacchetti del pane, e che vendano a privati in quantitร adeguate a privati (acquisto minimo 100 pezzi va bene, 1000 no, 10000 รจ decisamente troppo)?
Che non siano amazon / ebay / altre megapiattaforme.
Grazie, e i boost sono graditi
3 people like this
8 people reshared this
metro.it only sells to businesses, not individuals (it requires a partita iva)
np
(I wonder if that kind of restriction is a thing only in Italy and not elsewhere)
(I wonder if that kind of restriction is a thing only in Italy and not elsewhere)
Parade du Grotesque ๐ likes this.
I know some Metro shops are opened to the public here in France, which is why I mentioned it. But, yes, most are for professionals only.
you could search on ebay for it and then look if the seller has an own website with shop, many have :)
Elena ``of Valhalla'' likes this.
David de Groot ๐ reshared this.
me, playing klondikeยน during breakfast and wishing for the next card: โa king, any kinโฆ waitasecond! Nae king! Nae quin! Nae laird! Nae master! We willna be fooled again!โ
ยน as implemented by pysolfc
ยน as implemented by pysolfc
2 people like this
Elena ``of Valhalla'' reshared this.
Dresses and skirts with pockets.
Boost if you agree.
Boost if you agree.
3 people reshared this
A couple of weeks ago I baked https://www.nordickitchenstories.co.uk/2017/11/02/swedish-crispbread-knackebrod-recipe/
Today, I followed the same recipe. Except I've used 150 g buckwheat / 250 g wheat flour, wheat starter and malt instead of honey. And it's also good.
Served with white beans and parsley spread.
Today, I followed the same recipe. Except I've used 150 g buckwheat / 250 g wheat flour, wheat starter and malt instead of honey. And it's also good.
Served with white beans and parsley spread.
3 people like this
Elena ``of Valhalla'' reshared this.
Very balanced take on the #Stallman debate: https://www.arp242.net/rms.html
I do not agree with all of it, but I can get behind the criticism of specific passages in the open letter and the judgment on the fitness for leadership of rms is shared.
I do not agree with all of it, but I can get behind the criticism of specific passages in the open letter and the judgment on the fitness for leadership of rms is shared.
โฟ undฬทeฬทlฬทฤฬทtฬทeฬทdฬท reshared this.
I have never retracted anything, nor I intend to do so. As one of the first signers I stand behind what is written in the open letter.
I hope that is clear enough.
(I deduce from your messages that you cannot reconcile this with what I wrote in the message that started this thread. And I can live with that.)
I hope that is clear enough.
(I deduce from your messages that you cannot reconcile this with what I wrote in the message that started this thread. And I can live with that.)
I'm still curious as to what it is that you agree with that article when it comes to getting behind criticism of the open letter, while also standing behind the letter. it sounds a little contradictory to me, and I expect your stating what it was that you criticized would have made it clear, but I get and respect that you won't wish to specify what the criticism you also partially undersigned was, and prefer to leave it up for speculation. I acknowledge and appreciate the self-criticism you imply with this combination of actions. o-o
Elena ``of Valhalla'' reshared this.
Please, /please/, don't make /only/ videos, y'all! Make text articles too!
Text is even /easier/ to make it's just /always/ video
always
Not everyone can do videos. Especially long videos that we're expected to Sit Down And Focus Entirely On which means engaging speech parsing AND we can't easily back up and reread things like we could text and we /can't slow down/ like we could text and we can't skim like we could text and just
there's often /no point/ to it being a video and we /can't/.
Text is even /easier/ to make it's just /always/ video
always
Not everyone can do videos. Especially long videos that we're expected to Sit Down And Focus Entirely On which means engaging speech parsing AND we can't easily back up and reread things like we could text and we /can't slow down/ like we could text and we can't skim like we could text and just
there's often /no point/ to it being a video and we /can't/.
Tyng-Ruey Chuang reshared this.
PSA: quando bevete il caffรฉ, coinvolgete i vostri figli piccoli con una tazzina di caffรฉ d'orzo con la schiumetta sopra.
cosรฌ, quando da grandi si troveranno a non poter bere caffรฉ (o a doverlo ridurre drasticamente) per motivi di salute, avranno una bevanda calda di cui apprezzano il sapore perchรฉ gli ricorda l'infanzia, anzichรฉ doverlo cacciar giรน con disgusto mascherandolo con latte e simili.
(grazie mamma)
cosรฌ, quando da grandi si troveranno a non poter bere caffรฉ (o a doverlo ridurre drasticamente) per motivi di salute, avranno una bevanda calda di cui apprezzano il sapore perchรฉ gli ricorda l'infanzia, anzichรฉ doverlo cacciar giรน con disgusto mascherandolo con latte e simili.
(grazie mamma)
Yaku likes this.
Elena ``of Valhalla'' reshared this.
faried nawaz likes this.
7 people reshared this
Elena ``of Valhalla'' reshared this.
Content warning: RMS
โฟ undฬทeฬทlฬทฤฬทtฬทeฬทdฬท reshared this.
I think he is clearly unfit about being a leader in an organization, full stop.
Or at the very least, in any organization that is vaguely related to anything based on ethical principles.
Even without any consideration of moral judgement on him as a person.
Or at the very least, in any organization that is vaguely related to anything based on ethical principles.
Even without any consideration of moral judgement on him as a person.
2 people like this
Elena ``of Valhalla'' reshared this.
Week mostly eaten up by admin stuff, but nearly done with it. Look forward to returning to code.
Elena ``of Valhalla'' reshared this.
Sunday, I was happy to give a talk at the FSF #LibrePlanet, wearing the Tshirt I designed for them (photo). But later that day, Richard Stallman announced his return to the FSF's Board of Directors. In this situation, I'll no longer invest my energy for them... ๐ฟ
#fsf #rms
#fsf #rms
2 people like this
2 people reshared this
Nobody is claiming RMS is a saint - he even jokes about that himself, as you probably know - but it is a fact that he left the board because about a year ago he was accused with lies and slander about personal views he discussed on an issue whose seriousness he did not belittle and whose victims he did not blame, opinions he had respectfully issued in a friendly forum (a "safe space" in modern jargon). And that this is not the first time people misrepresent his controversial - but not evil and not even ill-meaning - views on social issues. Please see, if you haven't yet (sorry for not introducing them earlier, had to dig this up from year old mail archives):
https://sterling-archermedes.github.io/
https://jorgemorais.gitlab.io/justice-for-rms/index.html
Unfortunately, those lies and slanders have not been reflected upon at all by the accusers and are at the heart of the renewed attacks. In a more honest, respectful and humane community, this could have led to a productive discussion about his ideas and behavior, for which he is actually known to have retreated in some cases, and more importantly a discussion about our culture and how it embeds us with perspectives that the guillotine only silences but doesn't solve. Instead, what we have is a hard-line mob-rule mad-hatter witch-hunt smear campaign against an individual, that only detracts from our common cause, divides us and crystalizes oppositions, and profits our common opponents.
https://sterling-archermedes.github.io/
https://jorgemorais.gitlab.io/justice-for-rms/index.html
Unfortunately, those lies and slanders have not been reflected upon at all by the accusers and are at the heart of the renewed attacks. In a more honest, respectful and humane community, this could have led to a productive discussion about his ideas and behavior, for which he is actually known to have retreated in some cases, and more importantly a discussion about our culture and how it embeds us with perspectives that the guillotine only silences but doesn't solve. Instead, what we have is a hard-line mob-rule mad-hatter witch-hunt smear campaign against an individual, that only detracts from our common cause, divides us and crystalizes oppositions, and profits our common opponents.
Dear @David Revoy after reading this I also will stop to follow you.
All of you are confusing personal bias with actual facts, attacking RMS for a behavior which is probably spread over the 90% in whole IT industries at any level. We reached the point to decided if it is better mobbing RMS or closing on eye over GAFAM that every day besides making the world a worst place is injecting moneys in the open source and free software space. I think this is the real point.
All of you are confusing personal bias with actual facts, attacking RMS for a behavior which is probably spread over the 90% in whole IT industries at any level. We reached the point to decided if it is better mobbing RMS or closing on eye over GAFAM that every day besides making the world a worst place is injecting moneys in the open source and free software space. I think this is the real point.
Elena ``of Valhalla'' reshared this.
I feel a bit of a rant coming on. This is about software developer mindsets, but it's also about "processes", which can be a bit of a scary term to many developers.
I got quite lucky in my career, in two particular ways.
First, in my first job I struck up a pretty good relationship with our CTO. He and I had quite a few conversations about the why and wherefore of what we were doing, from a business rather than a development perspective. That has left me with an interest in the big picture.
I got quite lucky in my career, in two particular ways.
First, in my first job I struck up a pretty good relationship with our CTO. He and I had quite a few conversations about the why and wherefore of what we were doing, from a business rather than a development perspective. That has left me with an interest in the big picture.
So what does operations require from developers?
Developers often think of that in terms of "make things easy for ops", such as giving them a single binary to run instead of having them wade through configuration files. And to a degree, that's a fair enough goal to have for devs.
But the truth is, that ops tend to have some coding ability, and there are a ton of configuration management tools out there and in active use.
Complex setups that can be scripted aren't all that complex.
Developers often think of that in terms of "make things easy for ops", such as giving them a single binary to run instead of having them wade through configuration files. And to a degree, that's a fair enough goal to have for devs.
But the truth is, that ops tend to have some coding ability, and there are a ton of configuration management tools out there and in active use.
Complex setups that can be scripted aren't all that complex.
In fact, what operations require *more* from software is adaptability. The way devs tend to run software is usually *not* the way ops need to run it. Simplicity can be a bit of an own goal.
Or, to put it differently, while ops are end-users, they're not to be confused with grandpa trying to figure out this new-fangled electronic mail thingimajig.
What ops require above anything else from devs is boring.
No, really, that's it. Software should be boring.
That is, it should be predictable.
Or, to put it differently, while ops are end-users, they're not to be confused with grandpa trying to figure out this new-fangled electronic mail thingimajig.
What ops require above anything else from devs is boring.
No, really, that's it. Software should be boring.
That is, it should be predictable.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
2 people reshared this
Configuration file formats changing, interfaces changing, setup procedures changing, requirements changing - all of these things shouldn't happen.
Of course they will, and they will have to. That's where scripting helps ops out again. But that means that any change in what ops can reasonably expect must be documented and the documentation communicated in a manner that ops can deal with.
You cannot communicate this the day before a new release should go live.
Of course they will, and they will have to. That's where scripting helps ops out again. But that means that any change in what ops can reasonably expect must be documented and the documentation communicated in a manner that ops can deal with.
You cannot communicate this the day before a new release should go live.
Which brings me back to processes.
A process is nothing more than putting this communication in place.
The way this manifests is most typically through checklists. Follow steps a-z in your release from dev to ops.
But what these checklists *encapsulate* is the organisation's understanding of the needs of ops from devs (and vice versa for e.g. bug reporting procedures, etc.)
QA is usually in the middle of this process, adding the required check mark on one of the boxes on the list.
A process is nothing more than putting this communication in place.
The way this manifests is most typically through checklists. Follow steps a-z in your release from dev to ops.
But what these checklists *encapsulate* is the organisation's understanding of the needs of ops from devs (and vice versa for e.g. bug reporting procedures, etc.)
QA is usually in the middle of this process, adding the required check mark on one of the boxes on the list.
Every organisation has a process for this. Every single one of them. Even if it's "oh I just upload that JS file to the production server", that's a process.
It's a shitty one, but it is one.
What is often missing are the checklists. And some structured discussions around how to get to checklists. All of which is shorthand for communication.
The discussions tend to lead to more or less the same place: you either need a gate, or you need recovery.
It's a shitty one, but it is one.
What is often missing are the checklists. And some structured discussions around how to get to checklists. All of which is shorthand for communication.
The discussions tend to lead to more or less the same place: you either need a gate, or you need recovery.
A gate is a kind of barrier in the process that is somewhat cumbersome to pass, but if you have the right key, passing isn't all that hard.
QA is such a gate. If you cannot pass QA's requirements - which is usually in the form of regression tests and new feature tests - then you cannot go to production.
Recovery refers to the set of procedures you have for rolling back to the last known state in case of a production failure.
Recovery tends to be good in orgs with weak gates and vice versa.
QA is such a gate. If you cannot pass QA's requirements - which is usually in the form of regression tests and new feature tests - then you cannot go to production.
Recovery refers to the set of procedures you have for rolling back to the last known state in case of a production failure.
Recovery tends to be good in orgs with weak gates and vice versa.
I'm a bit traditionally minded here, and personally prefer my gates to be strong. The industry as a whole tends to prefer strong recovery. There is almost always a mixture of the two employed.
In the end, it barely matters. What matters is that the business goals are met reliably, and the delivery team is not unreasonably stressed out by their combined efforts.
What the whole thing requires regardless of the balance struck here is that developers take some ownership.
In the end, it barely matters. What matters is that the business goals are met reliably, and the delivery team is not unreasonably stressed out by their combined efforts.
What the whole thing requires regardless of the balance struck here is that developers take some ownership.
This isn't to say that developers "own" that everything goes smoothly. That would be an exaggeration.
But they cannot reasonably have the mindset that throwing code "over the wall" is their job. Their job is to provide to the next down the line - QA, ops, both - exactly what those parties require to do *their* respective jobs.
"Worked on my computer" is a symptom of this being broken, same as "no errors in the CI" or whatever form it takes.
But they cannot reasonably have the mindset that throwing code "over the wall" is their job. Their job is to provide to the next down the line - QA, ops, both - exactly what those parties require to do *their* respective jobs.
"Worked on my computer" is a symptom of this being broken, same as "no errors in the CI" or whatever form it takes.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
I sometimes exaggerate this and say "your job is only done when the end user - aka grandpa - successfully uses it to solve their problems". This is more for illustration purposes than as a real assignment of responsibilities. Exaggeration is a it double-edged, people can take it too seriously. But often enough it carries a general point across fairly well.
FOSS developers have a particularly hard time here. They are not part of an overall organization that provides the kind of feedback they need to optimize their output.
What I mean is, even if FOSS developers work towards their company internal goals and just publish software, the "organization" never includes all the users they end up factually delivering to, and communications with those users often relies on the users initiating it.
I don't know who uses my FOSS software, but they sure do.
What I mean is, even if FOSS developers work towards their company internal goals and just publish software, the "organization" never includes all the users they end up factually delivering to, and communications with those users often relies on the users initiating it.
I don't know who uses my FOSS software, but they sure do.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
As a FOSS developer, you have a few methods at your disposal to help you along here.
One is *prolific* documentation. But it doesn't just have to cover a lot of ground, it has to have entry points tailored to needs you may reasonably expect. The ops perspective is one such entry point.
Another is to double down on predictability. Infamously, Debian lags behind on up-to-date software and has slow "stable" release cycles. But it does just that, and it has generally earned them love from ops.
One is *prolific* documentation. But it doesn't just have to cover a lot of ground, it has to have entry points tailored to needs you may reasonably expect. The ops perspective is one such entry point.
Another is to double down on predictability. Infamously, Debian lags behind on up-to-date software and has slow "stable" release cycles. But it does just that, and it has generally earned them love from ops.
A third method is actually quite difficult to balance, but is still crucial: you have to bring the barriers to contribution way, way down.
Where this is often difficult is in bug reporting software. I see a lot of popular software using bots to classify bug reports according to developer needs, sometimes closing them automatically when the bot deems the report to be a duplicate or whatever.
There is limited developer bandwidth for dealing with reports, so they need screening of this kind.
Where this is often difficult is in bug reporting software. I see a lot of popular software using bots to classify bug reports according to developer needs, sometimes closing them automatically when the bot deems the report to be a duplicate or whatever.
There is limited developer bandwidth for dealing with reports, so they need screening of this kind.
Unfortunately, there is a negative result here for would-be contributors.
If you run into such bots, or excessive formalism in the report templates, or contributor agreements they need to sign before sending a patch, etc, etc, the most likely result is that people end up contributing less overall.
I can deal with all of that if it solves a problem I can't circumvent. But if it's easier to switch software than to contribute, well...
Lowering barriers may be better long-term.
If you run into such bots, or excessive formalism in the report templates, or contributor agreements they need to sign before sending a patch, etc, etc, the most likely result is that people end up contributing less overall.
I can deal with all of that if it solves a problem I can't circumvent. But if it's easier to switch software than to contribute, well...
Lowering barriers may be better long-term.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
If nothing else it signals "yes I want your contribution" even if one cannot deal with it immediately, as opposed to sending the signal that contribution is only appreciated conditionally.
This feeds into community management.
I believe - I have no data, sorry - that FOSS projects benefit strongly from human community managers that take care of this screening. And community management can in itself be a form of contribution.
See I started this thread on developers and ops interfacing, but...
This feeds into community management.
I believe - I have no data, sorry - that FOSS projects benefit strongly from human community managers that take care of this screening. And community management can in itself be a form of contribution.
See I started this thread on developers and ops interfacing, but...
... this goes right back to that beginning: FOSS developers that do not visible invest effort into interfacing with the "next" down the chain, which in this case are random people picking your software up, do not do their job.
They throw code over the wall. They say "it works on my computer", or "in my use-case".
I sometimes hear - heard the other day - that it's the developer's spare time, so one can't make such demands on them.
There's some truth there, absolutely.
They throw code over the wall. They say "it works on my computer", or "in my use-case".
I sometimes hear - heard the other day - that it's the developer's spare time, so one can't make such demands on them.
There's some truth there, absolutely.
So let's say I volunteer for the local fire brigade. We have a lot of volunteer fire response in Germany in smaller towns, which is supplemented by professionals from neighbouring larger towns. Response time often trumps equipment and experience.
Let's say I volunteer, but I don't respond to alarms. Or I do, but I always turn up late.
On the one hand, I'm volunteering my time, so one cannot make demands of me, right?
Let's say I volunteer, but I don't respond to alarms. Or I do, but I always turn up late.
On the one hand, I'm volunteering my time, so one cannot make demands of me, right?
But the kicker is, I am not actually volunteering for turning up in a red suit with a fire hose. That may be what it looks like, sure.
What I'm volunteering for is a job, one that is comprised both of rights and of responsibilities. If I ignore the responsibilities, people will rightly be upset.
So it is with the role of FOSS developer jobs. Nobody is asking for your coding time. Everyone is asking for your ability to solve user needs. Ignoring the user needs is not doing your *voluntary* job.
What I'm volunteering for is a job, one that is comprised both of rights and of responsibilities. If I ignore the responsibilities, people will rightly be upset.
So it is with the role of FOSS developer jobs. Nobody is asking for your coding time. Everyone is asking for your ability to solve user needs. Ignoring the user needs is not doing your *voluntary* job.
In practice, there will always be reasons for not always being able to meet responsibilities, and users should be adequately accepting of those. Practice is always full of complications, on a case-by-case basis.
It's the mindset that matters.
It's the mindset that matters.
in my previous job, I used to have sort of broken up the path to a form of devops, and was responsible for maintaining and educating the product devs on the build and deployment system, and the packaging for customer deployments.
Needless to say I had more than a few words with that one team leader who privately prided himself for not abiding with the process, and being a rockstar "break stuff" type of diva dev (he also was ingraining that mentality into his team mates), including that time where I had to educate him publicly on the all-devs mailing list with how to properly use the version control system so as not to hamper other teams' progress.
He also had his mind set on not reconciling conflicts regularly with his branch, and at one time was several *months* behind the main branch, which was of course against the agreed practices; I got vindicated when it took his team *two full weeks* to painfully merge their feature branch into the mainline, which I had (easily) predicted.
Fond memories...
Needless to say I had more than a few words with that one team leader who privately prided himself for not abiding with the process, and being a rockstar "break stuff" type of diva dev (he also was ingraining that mentality into his team mates), including that time where I had to educate him publicly on the all-devs mailing list with how to properly use the version control system so as not to hamper other teams' progress.
He also had his mind set on not reconciling conflicts regularly with his branch, and at one time was several *months* behind the main branch, which was of course against the agreed practices; I got vindicated when it took his team *two full weeks* to painfully merge their feature branch into the mainline, which I had (easily) predicted.
Fond memories...
I think the biggest problem is that most devs never work in ops.
A single coworker and I were ops in the past, and we both have a radically different perspective from our other dev peers.
We write things to make life easier for ops, and have ended up setting pro-ops policy for the rest of the team, especially since at least one of us is involved in every code review.
Of course, when you have a dev team with experience in ops, it quickly goes in the devops direction
A single coworker and I were ops in the past, and we both have a radically different perspective from our other dev peers.
We write things to make life easier for ops, and have ended up setting pro-ops policy for the rest of the team, especially since at least one of us is involved in every code review.
Of course, when you have a dev team with experience in ops, it quickly goes in the devops direction
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
As someone who's worked in ops for their entire career, and who has done development while doing that because things were thrown at us that didn't meet the needs of operations or customers, but "had to be deployed" because "I have no freaking idea at all, logic and common sense isn't something people do when choosing processes for operations or customers apparently"...
The number of developers who think that operations and customers are annoyances is far too high, and the number who wish to push problems that will be seen immediately by operations the second something hits 'production' to 'sometime in the future, not important' is far too high.
Devops just pushes that to production faster, meaning that if you're in devops, now the protections you had against some levels of stupidity and rushing headfirst over the cliff are removed, and you get to solve them with even less sleep.
All things in moderation. Devops + limits is ok.
The number of developers who think that operations and customers are annoyances is far too high, and the number who wish to push problems that will be seen immediately by operations the second something hits 'production' to 'sometime in the future, not important' is far too high.
Devops just pushes that to production faster, meaning that if you're in devops, now the protections you had against some levels of stupidity and rushing headfirst over the cliff are removed, and you get to solve them with even less sleep.
All things in moderation. Devops + limits is ok.
I've read things from some people like "not allowing developers on production machines is evil!"
those developers insisting on that NEVER answer the fscking phone when the customer can't get their things for their thing that will cost them all your business and theirs if it doesn't work, and why was it changed without notifying someone?
We used to say, when I was in the trucking industry, that losing a customer cost you 7 times more, to regain them as a customer, than keeping them.
I've seen more customers leave due to developers pushing shit into production "because we have to fail fast!" (the mentality of 'getting investor cash' - not 'keeping a customer.')
And then the investor money is gone, and your customers don't trust you because you keep screwing up production, and suddenly no one gets paid, and the fail fast person left to get a higher paying job and you stuck around to keep the place running.
Fsck those devs.
those developers insisting on that NEVER answer the fscking phone when the customer can't get their things for their thing that will cost them all your business and theirs if it doesn't work, and why was it changed without notifying someone?
We used to say, when I was in the trucking industry, that losing a customer cost you 7 times more, to regain them as a customer, than keeping them.
I've seen more customers leave due to developers pushing shit into production "because we have to fail fast!" (the mentality of 'getting investor cash' - not 'keeping a customer.')
And then the investor money is gone, and your customers don't trust you because you keep screwing up production, and suddenly no one gets paid, and the fail fast person left to get a higher paying job and you stuck around to keep the place running.
Fsck those devs.
Well, in our specific case devops works well because we happen to have two ops-minded developers who can keep the gates up, etc.
The main plus side of devops is that it aligns the incentives of devs and ops, because we have to directly deal with any problems we make for ourselves. If anything, the gates are stronger because I (or the other devops guy) can smackdown bad ideas earlier, at the very latest in code review.
The main plus side of devops is that it aligns the incentives of devs and ops, because we have to directly deal with any problems we make for ourselves. If anything, the gates are stronger because I (or the other devops guy) can smackdown bad ideas earlier, at the very latest in code review.
However, devops has many downsides. It's usually used as a cost cutting measure inappropriately.
It relies on a relatively rare combination of human resources: multiple developers with substantial ops experience.
It puts a heavy burden on the devops people (if they're doing their job correctly), and of course we aren't getting paid more. Ops work is also distracting, which breaks development flow, which is why they split in the first place
It relies on a relatively rare combination of human resources: multiple developers with substantial ops experience.
It puts a heavy burden on the devops people (if they're doing their job correctly), and of course we aren't getting paid more. Ops work is also distracting, which breaks development flow, which is why they split in the first place
That said, the reason devops has become more prevalent lately is that much mundane ops work (outside of infrastructure) can be automated.
A well designed system running on well designed infrastructure has minimal administrative overhead these days.
The problems arise from poorly designed systems and/or poorly designed or non-existent infrastructure, which is still the norm.
There'll always be a need for first responders as well.
A well designed system running on well designed infrastructure has minimal administrative overhead these days.
The problems arise from poorly designed systems and/or poorly designed or non-existent infrastructure, which is still the norm.
There'll always be a need for first responders as well.
Of course, terribly designed systems exist because of lackluster dev and management cultures, and a lack of good infrastructure is usually due to a lack in investment in infrastructure.
Ops/infrastructure never get the attention they deserve, since it's seen by management as a cost center to be cut, when really it's the bedrock for the whole operation.
Ops/infrastructure never get the attention they deserve, since it's seen by management as a cost center to be cut, when really it's the bedrock for the whole operation.
I find the point of view most helpful that sees DevOps as ops for devs. Which means it's an ops-driven thing, that just also takes dev needs into account. One example of that is actually containerisation; in itself it *complicates* ops.
But since container images can be deployed *and* given to devs', it's possible for devs to run more production like systems in which to integrate their software.
That may be a simplified description, but works.
But since container images can be deployed *and* given to devs', it's possible for devs to run more production like systems in which to integrate their software.
That may be a simplified description, but works.
As in, a lot of problems between ops and devs comes from this situation where software is just used vastly differently. When ops can decide on the major building blocks and gives a very limited set of tweakable knobs to devs, a lot of potential for confusion can be avoided.
Funny story, I was doing some hobby programming and wanted to use my program in a different context, and I suddenly realized that I had NO IDEA how to run my code outside of the IDE.
I immediately fixed this upon realizing it, but it snuck up on me as I hadn't been doing anything of any real importance.
I immediately fixed this upon realizing it, but it snuck up on me as I hadn't been doing anything of any real importance.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
what i often see, to overstretch your metaphors is people being paid to work for the fire brigade in the big city next to your little village and they come in with demands to your little volunteers fire bridge
i co-built a community of volunteer maintainers of puppet modules and i had someone at a conference come up to me and brag that he used us to train his junior engineers
๐คฆ๐ปโโ๏ธ
i co-built a community of volunteer maintainers of puppet modules and i had someone at a conference come up to me and brag that he used us to train his junior engineers
๐คฆ๐ปโโ๏ธ
I'm a savvy user, but know nothing about programming. Let me give you my take on this, OK?
Your job is only done when your software allows me to do more in less time than not having your software allows.
Most software does not pass this test. Indeed I think in my entire life of using ever-increasingly computerized systems, I can count on one hand where computers have improved things.
Yes. It is that stark.
Your job is only done when your software allows me to do more in less time than not having your software allows.
Most software does not pass this test. Indeed I think in my entire life of using ever-increasingly computerized systems, I can count on one hand where computers have improved things.
Yes. It is that stark.
As an example, at work we have a contact management system. Contact management is absolutely **KEY** to our business. If we screw this up, our business dies.
The contact management system, installed and configured by conslutants (sic) of the worst kind, is so unreliable that literally everybody who is client-facing prints off key clients into special notebook pages so that we can use those instead of this system.
The contact management system, installed and configured by conslutants (sic) of the worst kind, is so unreliable that literally everybody who is client-facing prints off key clients into special notebook pages so that we can use those instead of this system.
While this system is the most egregious of the lot, even a lot of COTS software we use is utter crap. I have a rhythm of automatically hitting Ctrl+S while working every five minutes or so, no matter what software I'm using (except that crap management system which manages to screw even "save" upโฆ) because out of nowhere the computer might suddenly decide that it's had enough and will throw a tantrum, losing any unsaved work.
I hear you.
I tend to think of this as more of a joint responsibility for the organizations that produce your software, while the developer's role is more limited. They have to do their part of the job to enable everyone else to, ultimately, fulfill this at the organizational level.
But as a shorthand, it absolutely is that stark.
I tend to think of this as more of a joint responsibility for the organizations that produce your software, while the developer's role is more limited. They have to do their part of the job to enable everyone else to, ultimately, fulfill this at the organizational level.
But as a shorthand, it absolutely is that stark.
I don't know. I think "not crashing" is a pretty basic requirement for all software, no? :D
Yes, but software can crash on particular inputs or on particular systems. It's unrealistic of developer-as-person to cover all of those, but developer-as-organization should at least reach a high percentage.
I'm looking more at developer-as-person here. Your requirement can be met by developer-as-organization without much involvement from developer-as-person.
Weird terminology, but maybe that makes sense?
I'm looking more at developer-as-person here. Your requirement can be met by developer-as-organization without much involvement from developer-as-person.
Weird terminology, but maybe that makes sense?
I guess? I've no idea what goes into making this stuff (no matter how much SO tries to explainโhe's an electrical engineer and works with thisโit goes in one ear and out the other, likely slipping out while I yawn ;)).
TL;DR is, there's an entire supply chain of specialized jobs involved.
It used to be so much simpler :)
It used to be so much simpler :)
So kind of like marketing, only more nerd-oriented. ๐คฃ
Oh, I've had the mixed pleasure of working in a "marketing technology" team for some months.
A lot of it was tech for SEO. But there was a bunch of non-SEO stuff done as well. Tech for generating landing pages with different funnels, based on the keywords that led to the page, etc.
I got a glimpse at both marketing itself and the spill over into tech here that was fascinating.
But yes, absolutely.
A lot of it was tech for SEO. But there was a bunch of non-SEO stuff done as well. Tech for generating landing pages with different funnels, based on the keywords that led to the page, etc.
I got a glimpse at both marketing itself and the spill over into tech here that was fascinating.
But yes, absolutely.
Marketing, when done properly, touches on literally every aspect of the business aside from accounting. (We haven't figured out a way to force accounting to do our bidding yet โฆ ๐
) Modern (not 4-Ps) marketing is all about figuring out what users want and then making sure the business fills that need.
Engineers are utterly BRILLIANT at making things. They tend to suck at knowing what needs to be built, though.
Engineers are utterly BRILLIANT at making things. They tend to suck at knowing what needs to be built, though.
yes good point, just as a shoval is bording but you can do intresting things with it.
i wrote this a long time ago, https://igalic.co/thoughts/2015-12-03-software-vs-automation.html i think it still mostly holds up
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ reshared this.
Elena ``of Valhalla'' reshared this.
I didn't know this was even a thing. Amiga UNIX.
Ivan Jurišiฤ reshared this.
Elena ``of Valhalla'' reshared this.
Ciao Fediverso!
Avete qualcosa in casa di cui vi volete liberare e vorreste donarlo a qualcuno?
Scattategli una foto ora e mettetela sul #fediverso con l'hashtag:
#mastoregalo
aggiungete una piccola descrizione dell'oggetto (ad esempio #divano, #CD, #DVD, #Libro) e la cittร dove รจ situato (#milano, #brescia, #verona) e chi รฉ interessato se lo viene a prendere e siamo tutti contenti: non gettiamo nulla e attiviamo una economia del riutilizzo.
iniziamo a condividere!!
Avete qualcosa in casa di cui vi volete liberare e vorreste donarlo a qualcuno?
Scattategli una foto ora e mettetela sul #fediverso con l'hashtag:
#mastoregalo
aggiungete una piccola descrizione dell'oggetto (ad esempio #divano, #CD, #DVD, #Libro) e la cittร dove รจ situato (#milano, #brescia, #verona) e chi รฉ interessato se lo viene a prendere e siamo tutti contenti: non gettiamo nulla e attiviamo una economia del riutilizzo.
iniziamo a condividere!!
Omar reshared this.
Bevilacqua Gustavino reshared this.
I'm using the solar oven for the first time this year, even if the temperature is still cold-ish (<15ยฐC) and windy.
The oven has reached almost 70ยฐC, even if the wind blew the cover and for a while the temperature fell down to 30ยฐC or so. I hope that the jar is reaching even more.
I'm baking apples, so whatever happens they are likely to be good (and safe to eat).
And now I should leave the computer and start sewing the fabric + mylar cover I've been postponing sewing forโฆ years, I suspect.
The oven has reached almost 70ยฐC, even if the wind blew the cover and for a while the temperature fell down to 30ยฐC or so. I hope that the jar is reaching even more.
I'm baking apples, so whatever happens they are likely to be good (and safe to eat).
And now I should leave the computer and start sewing the fabric + mylar cover I've been postponing sewing forโฆ years, I suspect.
7 people like this
Too late, the sun is going down, the #solarOven is back to 50ยฐC and the apples have already been moved to the haybox so that they remain warm until dinner.
But you can get a high quality picture of the haybox, taken with a pinephone, where you can also see a bit of the oven
(And yes, โhayboxโ means โrandom box from an online store, with shredded paper packaging material from another online store", and later I topped it up and wrapped the box in a blanket)
But you can get a high quality picture of the haybox, taken with a pinephone, where you can also see a bit of the oven
(And yes, โhayboxโ means โrandom box from an online store, with shredded paper packaging material from another online store", and later I topped it up and wrapped the box in a blanket)
Bevilacqua Gustavino likes this.
Elena ``of Valhalla'' reshared this.
๐ I wrote a bookbinding tutorial for you, so you can bind your own notebooks (or other books) from now on. 
http://backyard.fragmentscenario.com/bookbinding/bookbinding.html
#bookbinding #tutorial #art #zines @zine
http://backyard.fragmentscenario.com/bookbinding/bookbinding.html
#bookbinding #tutorial #art #zines @zine
Wobin d'Wonderdog reshared this.
TIL:
ok, it's not strictly true, it's trying to read from stdin, but since I didn't expect it to be splitting None, and it was deep in some async codeโฆ
https://bugs.python.org/issue27775
Thankfully it has been deprecated and it will go away:
https://docs.python.org/3/library/shlex.html
shlex.split(None) hangs forever.ok, it's not strictly true, it's trying to read from stdin, but since I didn't expect it to be splitting None, and it was deep in some async codeโฆ
https://bugs.python.org/issue27775
Thankfully it has been deprecated and it will go away:
https://docs.python.org/3/library/shlex.html
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
@Elena ``of Valhalla'' Wow, that's terrible behavior. Talk about violating the principle of least surprise.
and there is the additional surprise of python violating that principle, which is pretty unusual in itself.
Claes Wallin ๐ธ๐ช๐ญ๐ฐ likes this.
hot take: the somewhat glitchy notificationsยน on the pinephone aren't a bug, they are a feature.
They work this way to preserve your mental health by protecting you from constant notifications and the pressure to be always available for interruptions :D
ยน they tend not to work while the phone is suspended.
They work this way to preserve your mental health by protecting you from constant notifications and the pressure to be always available for interruptions :D
ยน they tend not to work while the phone is suspended.
2 people like this
paolog reshared this.
Wooo! new posts on the ex-urbe blog!
https://www.exurbe.com/who-we-think-has-the-power-to-change-the-world-transcript/
and another one is coming tomorrow!
https://www.exurbe.com/who-we-think-has-the-power-to-change-the-world-transcript/
and another one is coming tomorrow!
Samuele reshared this.
sono le sei meno venti, e a causa di un incrocio carpiato di confcall ho appena acceso il forno (elettrico) per la pizza della cena.
orario previsto per la cena: 18:30
#IRegretNothing #thisIsTheNorth
orario previsto per la cena: 18:30
#IRegretNothing #thisIsTheNorth
3 people like this
18:30 -> orario per la merenda! FORSE, al massimo, per l'aperitivo
Uh, happy birthday #ReText!
I have to confess that I use it mostly to preview reST files that I've written with vim, but it's one of those nice bits of software that I like to have installed.
Also, I've installed it on my #pinePhone and it works! :D
I have to confess that I use it mostly to preview reST files that I've written with vim, but it's one of those nice bits of software that I like to have installed.
Also, I've installed it on my #pinePhone and it works! :D
ReText turns 10 years โ mitya57โs weblog
Exactly ten years ago, in February 2011, the first commit in ReText git repository was made. It was just a single 364 lines Python file back then (now the project has more than 6000 lines of Python code).mitya57.me
2 people like this
I haven't heard ReText. I'll have to give it a try. It might be useful for some coworkers.
Elena ``of Valhalla'' likes this.
Testing of De Atramentis #inks continue.
I've finally finished the Pelikan 4001 in my preppy #fountainpen, and filled itยน with the De Atramentis Document Black
On good paper the lines are slightly wider than the Pelikan 4001, but still reasonable, and it writes nicely (a bit scratchy when reverse writing, but I don't think I can expect anything else when reverse writing on a japanese EF :D )
Then I tried on a bit of the worst printer paper I had around, and I can say โit worksโ. I could see the line getting wider as I writed, but the result isn't bad.
I also needed a test of the red, so I used a dip pen (with a flexible nib)
and these are the backs of the samples above, with some ghosting, but bleedthrough is really happening only when I flexed the nib.
And now, I need to find the strength of mind to wait until I have finished at least a bottle or two of other inks before buying the whole De Atramentis Document series :D (also, nope, that's way too expensive to buy at one time :D )
ยน not a full converter load, because I don't use it enough
@SlowRain
I've finally finished the Pelikan 4001 in my preppy #fountainpen, and filled itยน with the De Atramentis Document Black
On good paper the lines are slightly wider than the Pelikan 4001, but still reasonable, and it writes nicely (a bit scratchy when reverse writing, but I don't think I can expect anything else when reverse writing on a japanese EF :D )
Then I tried on a bit of the worst printer paper I had around, and I can say โit worksโ. I could see the line getting wider as I writed, but the result isn't bad.
I also needed a test of the red, so I used a dip pen (with a flexible nib)
and these are the backs of the samples above, with some ghosting, but bleedthrough is really happening only when I flexed the nib.
And now, I need to find the strength of mind to wait until I have finished at least a bottle or two of other inks before buying the whole De Atramentis Document series :D (also, nope, that's way too expensive to buy at one time :D )
ยน not a full converter load, because I don't use it enough
@SlowRain
3 people like this
I've not tried the De Atramentis Document inks ... I have their Salix which is an IG ink. Because they were easier to obtain here I've been using Platinum Carbon Black and Sailor Kiwa-Guro. For waterproof colours I like the Platinum Classic Ink IG series.
Isn't the salix from Rohrer and Klingner? I have their scabiosa (their purple-ish IG ink), but all IG inks aren't really waterproof as much as water resistant (i.e. what has been written will survive contact with water, but some dye can leak, and thus they can't be used e.g. with watercolours)
also, IG inks aren't completely lightfast, again a potential drawback when mixing them with watercolours โ or when writing labels that are exposed to the light :D
Neither is a problem when writing letters or inside a notebook, of couse.
also, IG inks aren't completely lightfast, again a potential drawback when mixing them with watercolours โ or when writing labels that are exposed to the light :D
Neither is a problem when writing letters or inside a notebook, of couse.
"Isnโt the salix from Rohrer and Klingner?" D'oh! of course it is. So I don't actually have any De Atramentis inks.
Elena ``of Valhalla'' reshared this.
Lo sapevate? Nella linkopedia del GL-Como ci sono diversi link relativi al #pinephone !
https://linkopedia.gl-como.it/search.html?q=tags:pinephone
https://linkopedia.gl-como.it/search.html?q=tags:pinephone
2 people like this
I've had a fix!
I've found the right incantation to enable the right agps on the #pinephone to get a fix in a reasonable amount of time (it was almost instantaneous, but the phone had been outside with gps but not agps-msb enabled for quite some time)
The script I've used to enable everything is:
(of course the last two are just to see that everything is setup correctly).
Now, I need to find out why Maps believes that the location services are disabled, and Settings is telling me that they are enabledโฆ
I've found the right incantation to enable the right agps on the #pinephone to get a fix in a reasonable amount of time (it was almost instantaneous, but the phone had been outside with gps but not agps-msb enabled for quite some time)
The script I've used to enable everything is:
#!/bin/sh
mmcli -m any --location-enable-3gpp
mmcli -m any --location-enable-gps-nmea
mmcli -m any --location-enable-agps-msb
mmcli -m any --location-status
mmcli -m any --location-get(of course the last two are just to see that everything is setup correctly).
Now, I need to find out why Maps believes that the location services are disabled, and Settings is telling me that they are enabledโฆ
Charles Stanhope reshared this.
A coworkerยน just pointed me to https://www.youtube.com/watch?v=hgI0p1zf31k
๐ต The PEP 8 Song ๐ต
ยน who is currently suffering through a (non blocking! I'm not evil) flake8 check I added to the CI of a project.
๐ต The PEP 8 Song ๐ต
ยน who is currently suffering through a (non blocking! I'm not evil) flake8 check I added to the CI of a project.
3 people like this
3 people reshared this
Elena ``of Valhalla'' reshared this.
Why haven't I found this piece earlier?
https://shkspr.mobi/blog/2017/11/captchas-dont-prove-youre-human-they-prove-youre-american/
https://shkspr.mobi/blog/2017/11/captchas-dont-prove-youre-human-they-prove-youre-american/
dogsleg likes this.
2 people reshared this
Taxis can be any color in the US. Because of movies, I too have defaulted into expecting yellow taxis. This does prove that cultural consideration needs to be thought out when serving these CAPTCHAs. I wonder how many Americans would successfully unlock a CAPTCHA if they had to choose exit signs from Street View images in Germany, Quรฉbec, or Spain.
Cannot agree more. In fact, in said blog post, an American outside New York City commented out the fact.
And also it doesn't help that not every American TV shows and films would feature someone hailing a taxi.
Good point on street signs as well, although so far it seemed like Google would serve Interstate-specific signs (I might be so wrong).
And also it doesn't help that not every American TV shows and films would feature someone hailing a taxi.
Good point on street signs as well, although so far it seemed like Google would serve Interstate-specific signs (I might be so wrong).
vi21 ๐น๐ญ likes this.
vi21 ๐น๐ญ reshared this.
Mark all the signs that point to the quaint German town of Ausgang! :D
Stampeding Longhorn likes this.
it has been too long since I last drove through a german speaking area :(
2 people like this
Elena ``of Valhalla'' reshared this.
Those trying to update their @mobian #pinephone for the first time after receiving it, should carefully read our post on the pitfalls during this first update. There are a few complications: https://blog.mobian-project.org/posts/2021/02/09/pam_issue/
LINux on MOBile reshared this.
Thank you for openly and clearly communicating about these issues!
/waiting 4 days for my phone to come!
/waiting 4 days for my phone to come!
If needing to reflash the OS to the phone, which image was it that was installed on the Pinephone Community Edition? Would https://images.mobian-project.org/pinephone/mobian-pinephone-phosh-20201215.img.gz be the right image to use?
Elena ``of Valhalla'' reshared this.
We would like to thank you all for attending, all the help from the many many volunteers and hope to see you (in person) again next year! Please help us improve by sending feedback to feedback@fosdem.org
janneke reshared this.
Elena ``of Valhalla'' 2 days ago
Elena ``of Valhalla'' 2 days ago