I did not refer to privacy rights. If you post a photo of yourselves online, you're giving up on a tiny part of your privacy rights. So my question still stands: would running your photos that you have taken of yourselves through a diffusion model rip your copyright of your photo?
So we have two positions here:
1) LLMs are trained on non-licensed information, so anything coming out of them must be created without a license, so no one should be allowed to use it.
2) LKMs are trained on public information, so everything coming out of the must be public domain.
These two positions are mutually exclusive and I feel that both are not entirely false, but also certainly not fully correct.
Is this true once you use a fancy filter of the photo app of your choice? Is this true once your phone applies such a filter without asking you? Should this be true for Theseus‘ Ship?
...and the author has lost me (I did read the entire post though).
> If GitHub is down today I can't deploy anyway so I might as well embrace the server requirement as a perk.
Just because you can't deploy doesn't mean others can't as well. (Also, GitHub != Git. Period.)
Heck, the entire idea of DVCS is that you should be able to continue to work even after the servers are down. If you can't, then it's not Git problem.
It seems that the author didn't even understand the concepts and ideas, or the rationals behind DVCS, let alone Git. As a someone who had lived through the period when SVN was the only game in town (and not wanting to return to those dark days), seeing the author pining for the "good 'ol days" of SVN-like, centralized VCS is just silly.
Yeah, the thing about us programmers is that we can build whatever stuff which is incompatible with the fundamental tool (centralized things vs. git(1)) on top of the tool and then complain that the tool has become useless. So it’s true that if you insist on having so much centralization that you become impotent once GitHub goes down, then yeah decentralization isn’t work for you—because you went out of your way to make it useless.
The sad thing is, having a mandatory high school level statistics & probability class alone is not enough, you'll also need a good curriculum and a competent teacher to go along with it. Otherwise, it wouldn't work: a bad curriculum taught badly by a unmotivated or unqualified teacher will almost always fail to teach the intuition, or, even worse, alienates students from the materials.
I have no idea why that reply got downvoted as well. It is essentially how I installed Firefox on my Debian stable laptop , and it has been working great as far.
I'm sorry, but what is stopping you or other people from using distros with faster release cycle or rolling release?
If anything, there are so many rolling release distros nowadays, that Debian Stable is a breath of fresh air in the sea of release first, fix later mentality (especially when it comes to desktop environment).
But I digress, in the end just choose the distro that suits your needs and requirements and be happy.
It's impossible when you just need pick up one distro and get new desktop software as it releases, and it also being supported by commercial vendors.
Amazing example of why linux desktop goes wrong direction is so many distros. When you have many answers – you don't have answer.
Ubuntu studio for artists, Kubuntu for those who like KDE, Debian for thos who don't like updates (._.), gentoo, etc etc.
Why on windows and mac user can compile, and update anything?
Just install photoshop (or newer version of gimp that available for majority of users on windows earlier than on linux before snap/appimage) and you get "distro" for artists.
And even snaps/appimages go wrong direction and overthink problem with security and sandboxing — when majority of users just need one runtime to deal with, like in SteamClient.
No one wants download or plug special repo/package for debian or fedora — this is amazing resource waisting! (insane even)
Interestingly, it was originally written in Python, but the author decided to rewrite the entire thing in Common Lisp due mainly to Python's poor performance and the lack of native thread support. The result Common Lisp version is 30 times faster than the old Python one. More info can be found in the author's blog post [1].
It is one of the most active implementation of Common Lisp (other being Clozure CL) and one of the fastest thanks to its support of optional type hinting (which it had long, long before gradual typing become in vogue recently). With some type hinting, it is possible to generate a code that's almost as fast as C (in certain cases, of course, but still much better than other implementations).
>Nobody seems to have done any serious work in SBCL in over a decade.
Could you please elaborate on what you mean by this?
SBCL releases a new version that contains both enhancements and bugfixes every couple of months, with the latest version (version 1.4.9, released on June 28, 2018, ~5 days ago) came one just one month after the previous version, 1.4.8, so I really don't understand what you mean when you said that no one "seems to have done any serious work in SBCL in over a decade".
Or did you meant to say that no one use SBCL to do serious work? Well, with some googling, I'm sure you'll be able to find that, while not many, there are companies that use SBCL (and other Common Lisp implementations) in production and other non-trivial works (not to mention various freelancers who use SBCL to put foods on the table). Some of those companies are also involves with the development of SBCL as well.
>Basic things are either completely missing or broken.
Care to list them? One of the strength of SBCL is that the devs are very responsive, especially to bug reports, so I'm sure they would be more than happy to fix the problems that you encountered.
Sure, here's 2 off the top of my head: Package management is a non-thing in SBCL. It just doesn't exist. Have fun downloading 6-to-12 year old zipballs. The basic HTTP server, hunchentoot IIRC, crashes after it serves its first request. Hope your favicon.ico was a good one!
>Package management is a non-thing in SBCL. It just doesn't exist.
When is the last time you use SBCL, or Common Lisp in general? Quicklisp (https://www.quicklisp.org/beta/), which is a modern package manager that supports resolving dependency and works across almost all currently active Common Lisp implementations (and not just SBCL), has been a thing for years now.
>The basic HTTP server, hunchentoot IIRC, crashes after it serves its first request
Would love to see the backtrace to see the reasons (and to submit a bug report if the issue warrant one), as from my experience Hunchentoot is very stable. I regularly used it in my freelance jobs without any issues.
> All that survived into Common Lisp but I am not up on the current state of lisp implementations and have no idea if people bother to take advantage of it any more.
There are implementations of Common Lisp, most notably CMU CL and SBCL, that take advantage of the (optional) type declaration of Common Lisp to increase efficiency and provide type checking.
Thank you for your hard work. I've just upgraded from Jessie to Stretch on my main laptop and the process is silky smooth.
Even though I only started using Debian with Jessie (was using Ubuntu and Arch before that), I've come to love and depend on Debian's quality, stability, and reliability.
