-
I didn’t manage to finish my D3.js spline code in time for my talk which I gave yesterday (which I think went really well, I loved the questions that I got!), so I’m going to try to finish it this weekend.
I also have to finish reviewing the last few chapters of a book for No Starch Press so I can collect my sweet sweet money for technical review.
-
I do not trust Software Freedom Conservancy (and with good reasons), but I agree with most of what is written here, except:
Copyright and other legal systems give authors the power to decide what license to choose […]
In my view, it’s a power which you don’t deserve — that allows you to restrict others.As an author of free software myself, I think that I totally deserve the right to decide who and how can use my work.
-
-
No.
I cannot trust them anymore, because when the project joined Conservancy, I explicitly asked them how my copyright was going to change and Karen Sandler replied that it was not going to change.
One year later I discovered that my name was completely removed by the sources.
According to the GPLv2 this violation causes a definitive termination of the project’s rights to use or modify the software.
Now, I informed Sandler about that mess (before the rebase) and never listen her back after, despite several of my contributions got “accidentally squashed” during the rebase.
That’s why I cannot trust them anymore.
Because they are still supporting a project that purposedly violated the GPLv2 (causing its definitive termination) and despite the fact that I gave them the possibility to fix this, they didn’t… and tried to remove all evidences of this violation and of the license termination with a rebase… (that still squashed some of my commits).
-
-
He’s objecting to restricting others in the way that proprietary software does, that’s the right he says you shouldn’t have. I think you edited out the part in your quote what bkuhn was talking about.
But more to your point, I also think that your right to to decide how others can use your work should be very limited. With software, an unlimited number of people can benefit from using your work in ways you may disagree with while you would be the only who would object. As a bargain with society, your authorial rights should be given smaller weight than the rights of your users.
-
As a bargain with society, your authorial rights should be given smaller weight than the rights of your users.
Is this a principle that you believe should be only applied to software?
Because if not, one could argue that a person’s special skills (say, as a doctor) are so valuable to society that that person should work for free to assure that the greatest number of people have access to their skill.
If the principle is restricted to expression, a photograph I take of a person could be freely used by a political party that I despise to further their cause through propaganda. I am only one person, and they are many. My pretty picture can help them more than it helps me. So according to the principle above (as I read it) they should have unrestricted access to my work.
I believe that the current regime of IP legislation is weighted too much towards copyright holders, but to argue that a creator should have no rights to decide how their work is used is going too far.
-
Software is different than doctors because software can be reproduced indefinitely without inconveniencing the author. Photographs are more similar to software than doctors.
I also didn’t say an author should have no rights. I just said their rights should weigh less. For example, copyrights should expire after, say, 10 years, instead of lasting forever as they de facto do now.
-
-
-
-
-
Oh, this is called uniform function call syntax (UFCS) in D and Nim. It does make code nicer to read in my experience.
-
I would also like to share this log from the epic epoch date of 123457890 (i.e. February 13, 2009) and its eponymous channel.
-
-
I’m preparing a talk for our local Papers We Love. I’m going to be talking about special splines! And I think I’m going to try to implement the algorithm in D3.js because I can’t figure out how else to quickly implement a nonstandard spline algorithm. If anyone has a suggestion, I’d be curious to hear it.
-
Interesting. A lot of people have told me to check out nim whenever I say how much I like D, and I definitely see the parallels. It even has UFCS, just like D! And D also has the same thing where unqualified imports are the same as
from foo import *in Python.I think those unqualified imports are less of a problem in D. Unlike with Python where namespace clashes can happen at runtime and be a huge (and silent!) surprise, namespace clashes in D (and hopefully nim) are much less of a problem because they’re quickly caught at compile time. I sort of understand the problem about reading a piece of code and not having a clear indication from reading it where a certain name came from. D has an optional
import foo: bar;syntax to only import thebarsymbol fromfoo. Does nim have this too?-
import the bar symbol from foo. Does nim have this too?
Yes :) The syntax is very close to how you said it.
from foo import barHere’s a real example:
from strutils import join
-
-
This is ill-advised.
You cannot define 1/0 and still have a field. There’s no value that works. Even when you do things like the extended real numbers where x/0 = infinity, you’re really just doing a kind of shorthand and you acknowledge that the result isn’t a field.
You can of course define any other algebraic structure you want and then say that operating on the expression 1/0 is all invalid because you didn’t define anything else and no other theorem applies, but this is not very helpful. You can make bad definitions that don’t generalise, sure, definitions that aren’t fields. But to paraphrase a famous mathematician, the difficulty lies not in the proofs but in knowing what to prove. The statement “1/0 = 0 and nothing else can be deduced from this” isn’t very interesting.
-
-
I want to make an attempt to clarify the discussion here because I think there is some substance I found interesting. I don’t have a strong opinion about this.
The article actually defines an algebraic structure with three operators: (S, +, *, /) with some axioms. It happens that these axioms makes it so (S, +, *) is a field (just like how the definition of a field makes (S, +) a group).
The article is right in saying that these axioms do not lead to a contradiction. And there are many non-trivial such structures.
However, the (potential) issue is that we don’t know nearly as much about these structures than we do about fields because any theorem about fields only apply to (S, +, *) instead of (S, +, *, /). So all the work would need to be redone. It could be said that the purpose of choosing a field in the first place is to benefit from existing knowledge and familiar expectations (which are no longer guarantteed).
I guess formally adding an operator means you should call it something else? (Just like how we don’t call fields a group even though it could be seen as a group with an added * operator.)
This has no bearing on the 1/0 = 0 question however, which still works from what’s discussed in the article.
-
As I understand it, you’ve only defined the expression 1/0 but you are saying that /0 isn’t shorthand for the multiplicative inverse of 0 as is normally the case for /x being x^-1, by definition. Instead, /0 is some other kind of magical non-invertible operation that maps 1 into 0 (and who knows what /0 maps everything else into). Kind of curious what it has to do with 0 at all.
So I guess you can do this, but then you haven’t defined division by zero at all, you’ve just added some notation that looks like division by zero but instead just defined some arbitrary function for some elements of your field.
If you do mean that /0 is division by zero, then 1/0 has to be, by definition, shorthand for 1*0^-1 and the arguments that you’ve already dismissed apply.
-
The definition of a field makes no statements about the multiplicative inverse of the additive identity (https://en.wikipedia.org/wiki/Field_(math)#Classic_definition). Defining it in a sound way does not invalidate any of the axioms required by the field, and, in fact, does define division by zero (tautologically). You end up with a field and some other stuff, which is still a field, in the same way that adding a multiplication operator on a group with the appropriate properties leaves you with a group and some other stuff.
The definition of the notation “a / b => a * b^-1” assumes that b is not zero. Thus, you may define the case when b is 0 to mean whatever you want.
That people want to hold on to some algebraic “identities” like multiplying by the denominator cancels it doesn’t change this. For that to work, you need the assumption that the denominator is not zero to begin with.
-
-
-
-
Indeed, it is the whole point. For a field, it doesn’t have to say anything about when you divide by zero. It is undefined. That doesn’t mean that you can’t work with and define a different, but still consistent, structure where it is defined. In fact, you can add the definition such that you still have the same field, and more.
edit: Note that this doesn’t mean that you’re defining a multiplicative inverse of zero. That can’t exist and still be a field.
-
In what way is it consistent? Consistent with what? As I understand it, you’re still saying that the expression 1/0 is an exception to every other theorem. What use is that? You still have to write a bunch of preconditions, even in Coq, saying how the denominator isn’t zero. What’s the point of such a definition?
It seems to me that all of this nonsense is about not wanting to get an exception when you encounter division by zero, but you’re just delaying the problem by having to get an exception whenever you try to reason with the expression 1/0.
-
I mean that the resulting structure is consistent with the field axioms. The conditions on dividing by zero never go away, correct. And yes, this is all about avoiding exceptions in the stack unwinding, programming language sense. The article is a response to the statements that defining division by zero in this way causes the structure to not be a field, or that it makes no mathematical sense. I am also just trying to respond to your statements that you can’t define it and maintain a field.
-
It really doesn’t make mathematical sense. You’re just giving the /0 expression some arbitrary value so that your computer doesn’t raise an exception, but what you’re defining there isn’t division except notationally. It doesn’t behave like a division at all. Make your computer do whatever you want, but it’s not division.
-
Mathematical sense depends on the set of axioms you choose. If a set of axioms is consistent, then it makes mathematical sense. You can disagree with the choices as much as you would like, but that has no bearing on the meaning. Do you have a proof that the resulting system is inconsistent, or even weaker, not a field?
-
I don’t even know what the resulting system is. Is it, shall we say, the field axioms? In short, a set on which two abelian operations are defined, with two distinct identities for each abelian operation, such that one operation distributes over the other? And you define an additional operation on the distributing operation that to each element maps its inverse, except for the identity which instead is mapped to the identity of the distributed-over operation?
-
-
-
You are correct. The field axioms are all still true, even if we extend / to be defined on 0.
The reason for this is that the axioms never “look at” any of the values x/0. They never speak of them. So they all hold regardless of what x/0 is.
That said, even though you can define x/0 without violating axioms it doesn’t mean you should. In fact it seems like a very bad idea to me.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
zeebo gave the same answer I would give:
a / bisamultiplied by the multiplicative inverse ofbwhenbis not zero. This article is all about howa / 0is not defined and so, from an engineering perspective, you can define it to be whatever you want without losing the property that your number representation forms a field. You claimed that defininga / 0 = 1means that your numbers aren’t a field, and all I’m saying is that the definition of the division operator is 100% completely orthogonal to whether or not your numbers form a field, because the definition of a field has nothing to say about division.-
What is an engineering perspective?
Also, this whole “a field definition doesn’t talk about division” is a bit of misunderstanding of mathematical idioms. The field definition does talk about division since “division” is just shorthand for “multiplicative inverse”. The reason the definition is written the way it is (excluding 0 from having a multiplicative inverse) is that giving zero a multiplicative inverse results in contradictions. When you say “ha! I won’t let that stop me! I’m going to define it anyway!” well, okay, but then either (1) you’re not definining a multiplicative inverse i.e. you’re not defining division or (2) you are defining a multiplicative inverse and you’re creating a contradiction.
-
-
-
-
-
-
-
-
JordiGH
edited
19 days ago
|
link
| on:
What do non-Emacs users use to navigate the commit history of git?
I use Mercurial via hg-git.
That gives me templating, revsets, hg absorb, Evolve, and a bunch of other goodies that make it really easy to read history and rewrite draft commits (and also rewrite published history, with a little bit of
--force, but I pretty much never do that).
-
How to Solve It - G. Polya.
-
-
Sounds like a good summary, but for much broader meaning of the word “problem” that would seem from it. The book gives a list of questions designed to explore the space around your problem from many different perspectives, hopefully guiding you towards a different problem that’s easier to solve, and will contribute necessary insight or data into your main one.
-
The idea is called divide and conquer.
-
Divide and conquer is a specific instance of that tactic. It’s one where solving the smaller problem actually gives you part of the solution of the larger problem. But in mathematics you often solve a truly simpler version of a problem to discover a strategy to attack the larger problem. The solution to the simpler problem itself is not used any more.
-
-
-
-
reissbaker
26 days ago
|
link
| on:
Rust compiler cannot be built without test failures on Debian and Fedora
Rust itself runs tests in CI on every pull request that are required to pass. For example, https://travis-ci.org/rust-lang/rust/builds/410084149
I can see why in a project as young as Rust maintaining different distributions’ forked build and test scripts for the compiler could be prioritized lower than e.g. language-level improvements.
-
Yes, Rust CI runs tests on x86_64. Hence lots of breakages on other Debian architectures.
I agree with you on the priority, but I am of the opinion that you can’t have it both ways. Either Rust should address test failures on other architectures, or Rust should stop claiming C level portability. Rust portability is “almost” there, but not there yet because other architectures are not maintained well.
-
Can you please point out where Rust “claims C level portability”?
-
This is one of those things where it doesn’t matter what the “official” stance but what the popular interpretation of that stance is. Certainly a number of people are writing Rust replacements for old C bastions, like grep or the coreutils. This along with the RIIR meme spreads the idea that Rust is a viable replacement for C in all situations, including portability.
If the RESF wants to be clearer about how Rust isn’t ready to replace C yet, they need to be clearer that it’s not ready instead of being silent on the point about portability claims and saying they never said that.
-
This is one of those things where it doesn’t matter what the “official” stance but what the popular interpretation of that stance is. Certainly a number of people are writing Rust replacements for old C bastions, like grep or the coreutils. This along with the RIIR meme spreads the idea that Rust is a viable replacement for C in all situations, including portability.
If the RESF wants to be clearer about how Rust isn’t ready to replace C yet, they need to be clearer that it’s not ready instead of being silent on the point about portability claims and saying they never said that.
I realize you’re probably just going to go bitch about me on IRC again, but your comment smells like a load of bullshit to me. Rust’s supported platform list looks like a pretty good indicator to me of what the platform support looks like. In fact, it looks like the exact opposite of “silence.”
saying they never said that.
I actually didn’t say that. I asked where we claimed C level portability. If we were doing such a thing, I’d want to know about it so we can correct it. Which is exactly the thing you’re blabbering on about. But no. Instead, I get RESF thrown in my face.
Lose, lose. Thanks for playing.
-
Aha, I also see this:
We do not demand that Rust run on “every possible platform”. It must eventually work without unnecessary compromises on widely-used hardware and software platforms.
So I guess the current situation with failing tests is entirely intentional but not well-known. Well, it should be better known.
-
-
-
-
I agree that Rust needs a better multi-architecture story - as someone who does embedded development, I’ll play with Rust but I’d be very wary of using it “for real” - but lack of serious support for non-x86 [EDIT: non-Windows/-Linux/-Mac] is pretty well-documented.
[EDITed in response to sanxiyn’s clarification, thanks!]
-
Rust Platform Support page is pretty clear. x86 is Tier-1, anything else is not.
-
-
-
-
Possibly unpopular opinions (and a large block of text) incoming:
C++, Go, Swift, D and Rust all fail to adequately replace C for me. When given the choice, I would likely choose to just stick with C (for the moment; I’ll talk about what I’m considering at the end).
C++ has so much historical baggage and issues, it’s already an immediate turn-off. More than that, it’s explicitly understood that you should carve out a subset of C++ to use as your language because trying to use the whole thing is a mess of sadness (given that it’s massive at this point). I appreciate the goal of zero-cost abstraction and having pleasant defaults in the standard library, but there are just too many problems for me to take it as a serious choice. Plus, I still have to deal with much of the unfortunate UB from C (not all of it, and honestly, I don’t mind UB in some cases; but a lot of the cases of UB in C that just make no reasonable sense come across to C++). It should be noted that I do still consider C++ occasionally in a C-with-templates style, but it’s still definitely not my preference.
Despite how often people place it here, I do not believe Go belongs in this group of candidates The garbage collection alone makes it unfit for systems programming. I see Go as a very reasonable choice to replace Java (but I don’t use Java whenever I have the choice, so I might not be the best person to ask). There are many other parts of this language that rub me the wrong way, but mostly, I just think it’s not a good systems language (but is instead a great intro language for higher-level stuff).
Swift is really easy to rule out: It’s not cross-platform. Even if it were, it has all sorts of terrible issues (have they fixed the massive compile times yet?) that make it a no-go.
D, as far as I can tell, manages to be C++ without the warts in a really lovely way. Having said that, it seems like we’re talking about good replacements for C, not C++, and D just doesn’t cut it for me. GC by-default (being able to turn that off is good, but I’ll still have to do it every time), keeping name mangling by-default, etc.
-betterChelps with some of this, but at that point, there’s just not enough reason for me to switch (especially with all the weirdness of there being two de facto standard libraries from different organizations, one of which I think is still closed-source?sounds like I might need to take another look at D; though, again, its emulation of C++ still suggests to me that it won’t quite cut it).Rust is the only language in this list that I think is actually a reasonable contender. Sadly, it still bites a lot of these issues: names are still mangled by-default, the generated binaries are huge (I’m still a little bugged that C’s hello-world with glibc dynamically links to 6KB), et al.
But more than all of these things I’ve listed, the problems I have with these languages is that they all have a pretty big agenda (to borrow a term from Jon Blow). They all (aside from C++ which has wandered in the desert for many years) have pretty specific goals with how they are designed to try and carve out their ideal of what programming should be instead of providing tools that allow for people to build what they need.
So, as for languages that I think might (someday, not soon really) actually replace C (for me):
Zig strikes a balance between C (plus compile-time execution to replace the preprocessor) and LLVM IR internals which allow for incredibly fine-grained control (Hello arbitrarily-sized, fixed-width integers, how are you doing?). It also manages to have the best C interop story I have ever seen in a language so far (you can import from C header files no problem, and zig libraries can have their code called from C also no problem; astounding).
Myr is still really new (so is Zig really), and has a lot left to figure out (e.g., its C interop story is not quite so nice yet). However, it manages to be incredibly simple and terse for a braced language. My guess is that, in the long run, myr will actually replace shell languages for me, but not C.
Jai looks incredibly cool and embraces a lot of what I’ve mentioned above in that it is not a big agenda language, but provides a lot of really useful tools so that you can use what you make of it. However, it’s been in development for four years and there is no publicly available implementation (and I am worried that it may end up being closed-source when it is released, if ever). I’m hoping for the best here, but am expecting dark storms ahead.
Okay, sorry for the massive post; let me just wrap up a few things. I do not mean to imply with this post that any of the languages above are inherently bad or wrong, only that they do not meet my expectations and needs in replacing C. For a brief sampling of languages that I love which suffer from all the problems I mentioned above and more, see here:
- Haskell and Idris, but really Agda
- Ada
- Lua
- APL (specifically, the unicode variants)
- Pony
They are all great and have brilliant ideas; they’re just not good for replacing C. :)
Now then, I’ll leave you all to it. :)
-
(especially with all the weirdness of there being two de facto standard libraries from different organizations, one of which I think is still closed-source?)
That was resolved a few years ago. D just has one stdlib, it’s fairly comprehensive, and keeps getting better with each release.
-
a few years ago
a bit of an understatement! The competing library was dropped in 2007.
-
-
Despite how often people place it here, I do not believe Go belongs in this group of candidates The garbage collection alone makes it unfit for systems programming. I see Go as a very reasonable choice to replace Java (but I don’t use Java whenever I have the choice, so I might not be the best person to ask). There are many other parts of this language that rub me the wrong way, but mostly, I just think it’s not a good systems language (but is instead a great intro language for higher-level stuff).
Agreed with this. Go is my go-to when I need to introduce dependencies to a Python script (and thus fuck with
pip --userorvirtualenvor blah blah blah) for high level glue code between various systems (e.g. AWS APIs, etc.)I think there’s a reason Go is dominating the operations/devops tooling world - benefits of static compilation, high level, easy to write.
Look at the amount of hacks Docker needs to do things like
reexecetc. to work properly in Go, that would be trivial to do in C. -
Note that Zig is x86-only at the moment. Check “Support Table” on Zig’s README.
For that matter, Rust is x86-only too, if you want Tier-1 support.
-
I’m a big d fan, but I agree that it’s the wrong thing to replace c. Betterc doesn’t really help in this respect, because it doesn’t address the root reason of why d is the wrong thing to replace c (which being that the language itself is big, not that the runtime or standard library are). Personally, I think zig is the future, but rust has a better shot at ‘making it’, and the most likely outcome is that c stays exactly where it currently is (which I’m okay with). I haven’t looked at myr (yet), and afaik isn’t jai targeted at game development? It might be used for systems programming, but I think it might not necessarily do well there.
It also manages to have the best C interop story I have ever seen in a language so far (you can import from C header files no problem, and zig libraries can have their code called from C also no problem; astounding)
I think nim does this, and d for sure does, with d++ (I think this may also help with the c++ emulation? Also, I’m not sure why you’re knocking it for its lack of quality c++ emulation when it’s afaik the only language that does even a mediocre job at c++).
-
I agree!
As for knocking D for emulating C++, I did not mean to suggest that doing so is a count against D as a language, but rather just as a count against replacing C. I already ruled out C++, if a given language is pretty close to C++, it’s probably also going to be ruled out.
It’s been a long time since I looked at nim, but generating C code leaves a really poor taste in my mouth, especially because of some decisions made in the language design early on (again, I haven’t looked in a while, perhaps some of those are better now).
As for Jai, yes it’s definitely targeted at game development; however, the more I look at it, the more it looks like it might be reasonable for a lot of other programming tasks. Again though, at the moment, it’s just vaporware, so I offer no guarantee on that point. :)
-
-
-
I suppose I know why, but I hate that D is always left out of discussions like this.
-
-
-
Yeah, me too. I really love D. Its metaprogramming alone is worth it.
For example, here is a compile-time parser generator:
-
This is a good point. I had to edit out a part on that a language without major adoption is less suitable since it may not get the resources it needs to stay current on all platforms. You could have the perfect language but if somehow it failed to gain momentum, it turns into somewhat of a risk anyhow.
-
-
-
-
Both https://github.com/janestreet/async and https://github.com/ocsigen/lwt allow concurrent programming in OCaml. Parallelism is what you’re talking about, and I think there are plenty of domains where single process parallelism is not very important.
-
You are right. There is Multicore OCaml, though: https://github.com/ocamllabs/ocaml-multicore
-
-
-
-
As of last year it’s open source, joining LDC
with discussions on HackerNews and Reddit.
-
-
-
-WliterallyAll would be very appreciated.
-
The historical reason why -Wall doesn’t enable all warnings is that warnings have been gradually added to the compiler over time. Adding new warnings to existing options could cause builds to fail after upgrading gcc.
Moreover, some pairs of warnings are incompatible (in the sense that any code accepted by one would be rejected by the other). An example of this is -Wstrict-prototypes and -Wtraditional.
-
The historical reason why -Wall doesn’t enable all warnings is that warnings have been gradually added to the compiler over time. Adding new warnings to existing options could cause builds to fail after upgrading gcc.
I’m aware of that, though I still find it wrong that -Wall doesn’t actually include the new warnings, a build breaking on upgrade with -Wall is in my opinion the more logical outcome. I would rather have flags like -Wall4.9 that would remain constant on upgrades so no one who’s just using that subset of the warnings breaks their build. -Wall can then remain true to its meaning. Seeing that the ship has sailed on that a long time ago, I still would like to have a -WliterallyAll (can be called something else) that would include -Wall -Wextra and others like -Wstrict-overflow.
Moreover, some pairs of warnings are incompatible (in the sense that any code accepted by one would be rejected by the other). An example of this is -Wstrict-prototypes and -Wtraditional.
These ones can’t be and don’t have to be included.
-
-
clangsupports-Weverythingwhich I’ve tried, and it happily spews out contradictory warnings (“Padding bytes added to this structure”, “No padding bytes have been added to this packed structure!”) along with (in my opinion) useless warnings (“converting char to int without cast”). -
-
These ones can’t be and don’t have to be included.
So your -WliterallyAll would not enable literally all warnings either? I’m not sure how that solves the problem.
I would rather have flags like -Wall4.9 that would remain constant on upgrades so no one who’s just using that subset of the warnings breaks their build. -Wall can then remain true to its meaning.
Now this is a neat idea that I can get behind.
-
-
Correction: I have been informed that new warnings actually have been added to -Wall on multiple occasions.
The better explanation for why -Wall leaves many warnings disabled is that many of them are just not useful most of the time. The manual states:
Note that some warning flags are not implied by -Wall. Some of them warn about constructions that users generally do not consider questionable, but which occasionally you might wish to check for; others warn about constructions that are necessary or hard to avoid in some cases, and there is no simple way to modify the code to suppress the warning.
In other words, it might be better to think of -Wall not as “all warnings”, but as “all generally useful warnings”.
-
-
-
-
This idea comes up from time to time. It’s an old idea. Here are two rms articles that address it.
https://www.gnu.org/licenses/hessla.html
https://www.gnu.org/philosophy/programs-must-not-limit-freedom-to-run.html
Basically: if you’re evil enough to do evil stuff, violating copyright is something you won’t think is very evil at all. So even without the argument about how impossible it is to define evil, a copyright-based license isn’t going to stop anyone from doing evil.
-
I don’t think this holds up in countries with established rule of law. It’s easy to forget that you can sue the government in court in the US and then the government will stop (at least most of the time). It’s just the overton window has shifted so much that we only think of “evil” in terms of things that don’t happen in this day and age, when terrible things are happening all the time and continue to be enabled by technology.
If there’s anything that unities most people, it’s the fear of having all their assets frozen. And the spectrum of evil stops way before “evil mastermind with 1000 offshore accounts and 20 fake identies”.
-
I agree. Julian Sanchez made this point about the NSA/CIA recently, that the bulk of their abuses of power inside the USA are either legal. If they’re not obviously legal, they often fall into a legal grey area, but the right person in the chain of command said that they were legal.
Career government officials tend to have a habit of following most rules of the organizations they inhabit, but may do a lot of shady things that don’t obviously violate those rules.
-
I think I should have read my own links. rms also argues that such restrictions on use based on copyright are likely unenforcible. I don’t recall ever reading about a case where someone violated a license’s conditions on usage (e.g. using Java in a nuclear reactor) and was thus found to be violating copyright. Has that happened?
-
Also: trying to sue the US government for copyright infringement because they used some software to facilitate torture (for example) doesn’t seem to me like a fruitful approach. Maybe with some optimism something could be done about human rights abuses in the US, but going the copyright infringement path doesn’t seem likely to work.
-
-
Glad to hear it’s been addressed already by gnu. I was thinking along similar lines, like “Eh, I see the problem, but I don’t think giving up freedom zero is the answer.” Of course, I don’t have a good solution either, other than a better more democratic government with well-informed citizens and a functioning justice system.
-
-
Forty-Bot
1 month ago
|
link
| on:
The Frontpage of Mastodon - I ranked all posts in the federiverse using the HN algorithm
switter.at seems to just be dating/mildly sexual ads?
-
-
Hail_Spacecake
1 month ago
|
link
| on:
The Frontpage of Mastodon - I ranked all posts in the federiverse using the HN algorithm
Yeah, why not post the source? Any reason why it only provides links to the posts, rather than an embedding of the post on the page?
-
-
On a related note, it’s also worth noting that the user control situation is even worse on mobile devices. You pretty much can’t buy phones or tablets with unlocked firmware that you can easily put your own operating system on.
-
Well there is the Librem at least.
-
-
This is correct. Purism routinely exaggerates about what they are able to provide in terms of openness, without any plausible way of actually delivering. It’s quite tiresome.
Not only will Librem 5 have blobs, they’ve now shamelessly announced they intend to use a loophole to procure FSF RYF certification despite this. If this is allowed to stand, it also makes RYF rather meaningless.
-
-
-
Also Fairphone:
We offer the ability to choose between the Google experience and the freedom of open source. Both versions are officially supported by Fairphone and we will provide continuous software updates.
In addition, and because the code is openly available, everybody is free to work on making other operating systems work on the Fairphone 2. The community already offers alternative operating systems like Sailfish OS, Ubuntu Touch and LineageOS.
-
Fairphone requires proprietary firmware blobs anyway.
-
-
As a Fairphone user: the market is made by buying the damned phones.
I wish there was an official Sailfish distro. I’m a happy user of the community port, but I also tolerate some glitches. Like not being able to calibrate the proximity sensor or run android apps.
But, as stated, they do have a non-Google android for those who want to be closer to the mainstream and a Google android for people who don’t care that much.
-
-
-
You can unlock the bootloader on most Android phones and you can run LineageOS or other AOSP forks, sometimes Ubuntu Touch and Sailfish ports, or postmarketOS.
You typically have to run the vendor android kernel fork if you want to have useful functionality, but some devices (Nexus 5, Nexus 7, Xperia Z2, Xperia Z2 Tablet) can run mainline Linux.
-
-
-
JordiGH
1 month ago
|
link
| on:
The Frontpage of Mastodon - I ranked all posts in the federiverse using the HN algorithm
Oy, careful with the Switter posts, those could be NSFW.
-
-
Travelling to Europython! Any other lobsters there?
I’m meeting up with friends and going to an opera concert.
Also I’ve been trying to toy around with really simple NLP stuff, just learning the basics, and want to continue that this weekend. I still don’t really know what I’m doing. What I want to do is be able to take an unstructured text document and extract a handful of specific things that I know are in there, but I don’t know how to do this yet and I’m not even sure what to Google for. If anyone has any tips for me that would be appreciated. :)
Oh, cool, what opera?