https://github.com/tanrax/thankful-eyes-theme.el
Enjoy!
#emacs #accessibility
https://github.com/tanrax/thankful-eyes-theme.el
Enjoy!
#emacs #accessibility
@javivf @lafe @melyanna @nff @shreyan
You may also want to renovate an old abandoned manor!?
- System Design Interview Vol. 1 and 2, Alex Xu and Sahn Lam
- Designing Data-Intensive Applications, Martin Kleppmann
- System Design Interview Vol. 1 and 2, Alex Xu and Sahn Lam
- Designing Data-Intensive Applications, Martin Kleppmann
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87922/highlight/true#M33705
TLDR? It's bull. Let's dive in?
They focus basically in saying three things:
1) Mozilla needs a license to your data to do things like sending your words to a search engine;
2) there's #AI stuff that needs ToS and Priv. Policy;
3) the acceptable use policy was already in place at Mozilla for the website, etc..
Why bull?
1) if what I type on Firefox (the browser) was sent to Mozilla so they could send it to the search engine, then they'd need access to it. It's not how a browser works or how a privacy-caring browser should ever work. Since what goes on between my Firefox textfields and the browsers I submit to is between us and then, Mozilla should have nothing to do with that data, with or without license.
2) They talk about two kinds of AI: AI services you can access to from Firefox, and AI offline and private abilities within Firefox. For the first, each of those services - if we choose to use them - can and should have their own ToS (distinct from Firefox or any other software used to reach them). AI services running locally should never share anything with anyone, so there's no licenses Mozilla should get.
3) Keep your website's ToS to your website, I don't need it on Firefox - and Mozilla neither.
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87922/highlight/true#M33705
TLDR? It's bull. Let's dive in?
They focus basically in saying three things:
1) Mozilla needs a license to your data to do things like sending your words to a search engine;
2) there's #AI stuff that needs ToS and Priv. Policy;
3) the acceptable use policy was already in place at Mozilla for the website, etc..
Why bull?
1) if what I type on Firefox (the browser) was sent to Mozilla so they could send it to the search engine, then they'd need access to it. It's not how a browser works or how a privacy-caring browser should ever work. Since what goes on between my Firefox textfields and the browsers I submit to is between us and then, Mozilla should have nothing to do with that data, with or without license.
2) They talk about two kinds of AI: AI services you can access to from Firefox, and AI offline and private abilities within Firefox. For the first, each of those services - if we choose to use them - can and should have their own ToS (distinct from Firefox or any other software used to reach them). AI services running locally should never share anything with anyone, so there's no licenses Mozilla should get.
3) Keep your website's ToS to your website, I don't need it on Firefox - and Mozilla neither.
.txt file:description = ðŸ—Perhaps your nginx server is missing a
Content-Type: text/html; charset=utf-8 header?https://serverfault.com/a/975289
In
timeline it looks OK however, I think it's relying on> The file must be encoded with UTF-8
of the original spec:
https://twtxt.readthedocs.io/en/latest/user/twtxtfile.html
http(s)://domain.tls is not a valid resource, but http(s)://domain.tls/ is, as you can see here: https://stackoverflow.com/a/2581423I suppose that internally the wget/curl or whatever client you are using is redirecting it?
Feed was redirected: https://twtxt.andros.dev -> https://twtxt.andros.dev/
Each time my client fetches your feed. It just doesn't make any sense to me. Wouldn't be both, pretty much, be the same (I noticed the
/, yes)?
Feed was redirected: https://twtxt.andros.dev -> https://twtxt.andros.dev/
Each time my client fetches your feed. It just doesn't make any sense to me. Wouldn't be both, pretty much, be the same (I noticed the
/, yes)?
brew applications. Want to keep it lean!
brew applications. Want to keep it lean!
DVAR - Bedrii Wedrii
https://dvar.bandcamp.com/track/bedrii-wedrii
foto do CD "fayah!" dos DVAR, de onde veio a música escolhida esta semana
DVAR - Bedrii Wedrii
https://dvar.bandcamp.com/track/bedrii-wedrii
foto do CD "fayah!" dos DVAR, de onde veio a música escolhida esta semana
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87735
There they tell users that "You stay in control". Unfortunately, their new Terms of Use say that:
"Every once in a while, Mozilla may decide to update these Terms. We will post the updated Terms online. We will take your continued use of Firefox as acceptance of such changes."
No matter how common this has become over the past years, this is quite unacceptable, and Firefox users deserve better from Mozilla. The fact that they can unilaterally change the terms and users are automatically bound to them (as soon as they use the browser again - even if they're using it to open the document where they can see the date on the terms!) is not a fair agreement - and works against the claim that "You stay in control".
https://connect.mozilla.org/t5/discussions/information-about-the-new-terms-of-use-and-updated-privacy/m-p/87735
There they tell users that "You stay in control". Unfortunately, their new Terms of Use say that:
"Every once in a while, Mozilla may decide to update these Terms. We will post the updated Terms online. We will take your continued use of Firefox as acceptance of such changes."
No matter how common this has become over the past years, this is quite unacceptable, and Firefox users deserve better from Mozilla. The fact that they can unilaterally change the terms and users are automatically bound to them (as soon as they use the browser again - even if they're using it to open the document where they can see the date on the terms!) is not a fair agreement - and works against the claim that "You stay in control".
"We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example."
In the explanation, they don't tell us -what- is that "some basic functionality" they refer to, or why would Mozilla need to use information typed into Firefox, for example.
"We need a license to allow us to make some of the basic functionality of Firefox possible. Without it, we couldn’t use information typed into Firefox, for example."
In the explanation, they don't tell us -what- is that "some basic functionality" they refer to, or why would Mozilla need to use information typed into Firefox, for example.
But of course, everyone is welcome to take a look at https://github.com/upputter/TwtxtReaderMK1
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
> To me it appeared that the failed attempts to ban NPD in the past actually helped them gain more supporters.
What makes AfD stronger *for sure* is just going “lol nah we’re not even going to try”:
https://www.tagesschau.de/inland/innenpolitik/afd-verbot-antrag-100.html
If they don’t try, then it means that “it can’t be that bad, it’s just a normal party”, right? 😡
I have the books but they don't grow much more past interview level.
I have the books but they don't grow much more past interview level.
ugh, work pushing this late again. just got it done.
#running #treadmill
ugh, work pushing this late again. just got it done.
#running #treadmill
ugh, work pushing this late again. just got it done.
#running #treadmill
If you just asked "WTF?", welcome to the club.
Of course, this doesn't make sense, it couldn't be just like that... so I went on and read the terms. The trick is specifically on this bit:
"These Terms only apply to the Executable Code version of Firefox, not the Firefox source code."
So sure, Firefox is still the Free Software codebase you were used to, only now if you want to use not the code but Mozilla's distributed binaries, you'll do so while also agreeing to some Terms of Use and Privacy Policy.
The trick is, of course, to not use their binaries. In practice, things are a bit trickier. Ubuntu, for instance, was more than happy to ditch their self-compiled Firefox packages and use Mozilla-provided snaps instead.
But trickier or not... well, Mozilla has just made an unhappy user base unhappier - and I hope they reap what they are sowing.
@sarahjamielewis@sarahjamielewis https://mastodon.social/@sarahjamielewis/114072293410465140
If you just asked "WTF?", welcome to the club.
Of course, this doesn't make sense, it couldn't be just like that... so I went on and read the terms. The trick is specifically on this bit:
"These Terms only apply to the Executable Code version of Firefox, not the Firefox source code."
So sure, Firefox is still the Free Software codebase you were used to, only now if you want to use not the code but Mozilla's distributed binaries, you'll do so while also agreeing to some Terms of Use and Privacy Policy.
The trick is, of course, to not use their binaries. In practice, things are a bit trickier. Ubuntu, for instance, was more than happy to ditch their self-compiled Firefox packages and use Mozilla-provided snaps instead.
But trickier or not... well, Mozilla has just made an unhappy user base unhappier - and I hope they reap what they are sowing.
@sarahjamielewis@sarahjamielewis https://mastodon.social/@sarahjamielewis/114072293410465140
As for the potentially reduced code coverage with a non-TDD approach, I can easily see which parts are lacking tests and hand them in later. So, that's largely a specious argument. Granted, I can forget to check the coverage or simply ignore it.
I agree with John, TDD results in less elegant code or requires more refactoring to tidy it up. Sometimes, it's also not entirely clear at the beginning how the API should really look like. It doesn't happen often, but it does happen. Especially when experimenting or trying out different approaches. With TDD, I then also have to refactor the tests which is not only annoying, but also involves the danger of accidentally breaking them.
TDD only works really well, if you have super tiny functions. But we already established that I typically don't like tiny methods just for the purpose of them being extremely short.
When fixing a bug, I usually come up with a failing test case first to verify that my repaired code later actually resolves the problem. For new code, it depends, sometimes tests first, sometimes the productive code first. Starting off with the tests requires the API to be well defined beforehand.
As for the potentially reduced code coverage with a non-TDD approach, I can easily see which parts are lacking tests and hand them in later. So, that's largely a specious argument. Granted, I can forget to check the coverage or simply ignore it.
I agree with John, TDD results in less elegant code or requires more refactoring to tidy it up. Sometimes, it's also not entirely clear at the beginning how the API should really look like. It doesn't happen often, but it does happen. Especially when experimenting or trying out different approaches. With TDD, I then also have to refactor the tests which is not only annoying, but also involves the danger of accidentally breaking them.
TDD only works really well, if you have super tiny functions. But we already established that I typically don't like tiny methods just for the purpose of them being extremely short.
When fixing a bug, I usually come up with a failing test case first to verify that my repaired code later actually resolves the problem. For new code, it depends, sometimes tests first, sometimes the productive code first. Starting off with the tests requires the API to be well defined beforehand.
Dear Internet, can you prove them wrong and tell me what "Heller" from this tin box used to be?
"Heller", a metal logo on a tin box' lid, both a bit rusty.
Dear Internet, can you prove them wrong and tell me what "Heller" from this tin box used to be?
"Heller", a metal logo on a tin box' lid, both a bit rusty.
I didn't come across John Ousterhout or any of his work before, at least not deliberately. So, this document is my first contact.
I only finished the chapter on comments and I totally agree with John so far. This document just manifests to me how weird Bob's view is on certain subjects.
I always disagreed with the concept of a maximum method length. Sure, generally, shorter functions are probably better, but it always depends. And I've certainly seen super short methods that just made the code flow even worse to follow. While "one function should only do one thing" is a nice general rule, I'm 100% in team John with the shown examples. There are cases, where this doesn't help readability at all. Not even close.
To me, a function always has to justify its existence. Either by reusing it at least at another place or by coming up with dedicated tests for it. But if it is just called once and there are no tests, I almost always decide against it. Personally, I don't mind longer methods. We just recently had a discussion about that and I lost against two other workmates who are more in Uncle Bob's camp, they refactored one medium sized method into three very short ones. Luckily, we agree on most other topics.
Lol, what!? The shorter the method, the longer the variables inside? I first thought I misread or the writeup mixed it up. I'll always do it the other way around.
I've been also bitten badly by outdated comments in the past, but Bob must have worked on really terrible projects to end up with such an attitude to dislike comments. Oh well. No doubt, I've come across by several orders of magnitude more useless comments, in my experience (autogenerated) JavaDocs fall in the category more frequently than not. So, I know that there are different types of comments. A comment doesn't automatically mean that it is good and justified.
But I also partially agree with Bob and John and think that a good name has a proper chance to save a comment. Though, when in doubt, I go John's route and use a shorter name with a comment rather than use a kilometer long identifier. Writing good comments typically takes some time, sometimes much longer than writing the code. It regularly takes me several minutes. It's a hard art.
I perhaps should read up on John's work. He seems to be more reasonable and likeminded. :-) Let me continue to complete this document.
I didn't come across John Ousterhout or any of his work before, at least not deliberately. So, this document is my first contact.
I only finished the chapter on comments and I totally agree with John so far. This document just manifests to me how weird Bob's view is on certain subjects.
I always disagreed with the concept of a maximum method length. Sure, generally, shorter functions are probably better, but it always depends. And I've certainly seen super short methods that just made the code flow even worse to follow. While "one function should only do one thing" is a nice general rule, I'm 100% in team John with the shown examples. There are cases, where this doesn't help readability at all. Not even close.
To me, a function always has to justify its existence. Either by reusing it at least at another place or by coming up with dedicated tests for it. But if it is just called once and there are no tests, I almost always decide against it. Personally, I don't mind longer methods. We just recently had a discussion about that and I lost against two other workmates who are more in Uncle Bob's camp, they refactored one medium sized method into three very short ones. Luckily, we agree on most other topics.
Lol, what!? The shorter the method, the longer the variables inside? I first thought I misread or the writeup mixed it up. I'll always do it the other way around.
I've been also bitten badly by outdated comments in the past, but Bob must have worked on really terrible projects to end up with such an attitude to dislike comments. Oh well. No doubt, I've come across by several orders of magnitude more useless comments, in my experience (autogenerated) JavaDocs fall in the category more frequently than not. So, I know that there are different types of comments. A comment doesn't automatically mean that it is good and justified.
But I also partially agree with Bob and John and think that a good name has a proper chance to save a comment. Though, when in doubt, I go John's route and use a shorter name with a comment rather than use a kilometer long identifier. Writing good comments typically takes some time, sometimes much longer than writing the code. It regularly takes me several minutes. It's a hard art.
I perhaps should read up on John's work. He seems to be more reasonable and likeminded. :-) Let me continue to complete this document.
I know, the great is enemy of the good, we all have Things To Do (TM), and that's not your core business.
I've heard it all, and I know: there is a million reasons not to do something, specially if it doesn't affect you particularly. That’s why we (still?) have buildings with stairs but no ramps, digital systems without backups... or infrastructure running on proprietary third-parties.
I know, I've heard it all. You'd love to, but you really don't have an alternative to google docs yet, zoom can't be that bad anyway since everyone seems to use it, and here's our form you have to fill in - hosted by Qualtrics. Between the "you don't care because it isn't a problem to you" and the "I get you, I really do, but I don’t have the means to switch", we both know that your parents group will either remain on WhatsApp or move away from it "soon".
The problem is, it is already too late. What if there's someone needing their union, but the conversation happens over slack?
I know, change is hard. But it is also needed.
@dangoodin@dangoodin https://infosec.exchange/@dangoodin/114034183325328927