The link in question is actually "http://yurivish.com/Silk%20Static/Silkura%20-May%2002%20-loo... - yurivish.com seems to be a loop to localhost (maybe broken DNS or something, I don't know). Apparently it's supposed to have some music playing in the background, as is also indicated in the message when you click the question icon in the top right corner.
Hmm... is there an archive for DNS entries, like the Internet Archive acts as for actual content?
Edit: Apparently there is dnshistory.org. Looks like the registration expired for that domain in 2013, so I don't know why it's resolving to anything. But the A record used to point to 74.208.41.229, which seems to still be listening on port 80 but is just 404ing.
Think of it in terms of free software identity politics, or free software deontological ethics. In these terms lack of a multi-stakeholder copyleft (or single stakeholder committed to free software) invites identity crisis or immoral behavior, and presence of an enterprise (ie proprietary) version is identity crisis and is immoral. Therefore in those terms, the argument you're replying to is in favor of Kallithea.
If you're not thinking in those terms, the argument you're replying to might seem irrelevant, or even in favor of Gitlab, if eg you prefer a permissive license or the software you use to have a profitable business behind it. Maybe that's where you're coming from?
About 'correctness' and 'small size' ... as soon as they'd add unittests as extensive as V8, JSCore, or SpiderMonkey, it'd grow big quite dramatically. :-)
I'd be interested to see how ES5-compliant MuJS really is. My guess is probably different from what they claim.
And what if those companies wish to provide their software to customers? Enter a terrible hell of "how are we going to relicense our stuff", that'll most likely end up with said companies switching to a different library.
No, the GPL, especially the AGPL is inherently bad for libraries. Libraries, mind you, not software in general. Like I've written in my other comment, the LGPL solves this issue painlessly.
Besides that, node.js won't run with MuJS, because node.js depends on V8 and libevent. Unless some poor sod actually reimplements the entire nodejs stack... but I hope people are smarter than that. :-)
Guys, it's double licensed. You are describing exactly the point: they don't want companies to use this without paying. Pay, and you can redistribute it to your clients.
This is basically for-profit code from a for-profit company, with a side dish of "open source for open source projects." It's like... like Github. Like Travis-CI. Like QT.
> Guys, it's double licensed. You are describing exactly the point: they don't want companies to use this without paying. Pay, and you can redistribute it to your clients.
Or you can release your code under the AGPL and keep all your money.
> This is basically for-profit code from a for-profit company, with a side dish of "open source for open source projects." It's like... like Github. Like Travis-CI. Like QT.
This is not like Github. Github does not release all of the source code powering their app.
> And what if those companies wish to provide their software to customers?
They can abide by the free license, or pay for a different license. Or, yes, switch to a different library. They are not entitled to use this library, nor any other library.
> No, the GPL, especially the AGPL is inherently bad for libraries.
If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
>They can abide by the free license, or pay for a different license
Or... use a library that suffers none of these issues. :-)
My point is about the clause in the GPL that enforces developers to enclose the source of their entire software, not just the library. The LGPL however, does not require that, which is why the LGPL is also occasionally called "GNU Library License" (though the 'L' in LGPL stands for 'Lesser').
And lets not nitpick here, the GPL isn't exactly subtle about these things.
>If this library were not available under any sort of open-source license, would you be making the same post, insisting it's "bad" for them not to give you free stuff?
No. It's their right to choose whatever license they wish, but it's also my right to not choose their software.
> Nitpick about what? Subtle about what? What are you talking about?
The clause I mentioned. I'm sorry if I was ambigious, but there were discussions in the past hovering about how the GPL still allows commercial software, and such. Yes, of course the GPL allows you to make good money, but in just about every example given, the actual bulk of the money isn't made from the software, but from the hardware the software just so happens to be running on (i.e., modems, smartphones, branded computers, mainframes, chipcards, etc).
> Under what moral code is it bad to offer alternative prices for alternative terms?
By claiming to offer Free Software™ with a very restrictive copyleft license with one hand, and expecting a 3-4 figure with the other in case you plan to use it on anything else than free software.
It's a little bit like imprisoning someone for their own safety, and expecting money if they wish to breath a little air.
I never claimed that there's anything wrong with the GPL/AGPL, but I do claim that there are cases where the GPL is a good choice, and then there are cases where it is not.
Maybe it's just me, but I'm not a particular fan of Lua-inspired pseudo-stackbased APIs.
I'm not sure why so many language devs insist on this terrible design. I fail to see anything good about it; It doesn't make the code smaller, it doesn't make the code faster, but it does make abstraction a royal pain in the buttocks.
Also, they couldn't have possibly chosen a worse license for a library that is going to most likely embedded statically in a program. Of all licenses, why AGPL? If it has to be GPL (whyever is none of my concern), why not LGPL?
Explicit stack-based interfaces are used for good reason: This allows simple accurate garbage collection (see eg. the Ruby API which requires somewhat error-prone conservative GC, Python which requires refcounts all over the place, or OCaml which requires annotating all local variables in a special block). A custom frame stack is also needed to have coroutines in pure ANSI C (two of the reasons Lua is popular).
I don't believe non-stack based APIs prevent the implementation of the features you just mentioned. You don't necessarily have to expose the underlying stack manipulation routines as your defacto API although it is easier to do so. My gripe with this technique is that it makes it much harder for the compiler to catch errors. Personally, I think it would be better to expose the API as helper functions that compose (and hide) the underlying stack routines.
The intent is clearly to promote sales of commercial licenses. Similar to why Oracle relicensed Berkeley DB from BSD to AGPL: “As of July 2011, Oracle's list price for non-copyleft Berkeley DB licenses varies between 900 and 13,800 USD per processor.” https://en.wikipedia.org/wiki/Berkeley_DB#Licensing
The grand majority of programming language APIs do not use a stack-based API.
Really, stack-based APIs are an exception in just about every way, but not in a good way.
If your question is about cheap memory storage, linked list algorithms already exist, so there's really no good reason to use a faux stack to store data.
It's not so much about what I would like to see, but rather why some developers insist on copying Lua's stack-based API, merely because so many people have accepted Lua as the very definition of a lightweight, embeddable programming language.
It seems like a false promise to me is all I'm saying. People get lured in with a very questionable tactic, and then start to believe "stack-based API == tiny and great", whereas I think that this is a pretty bold statement.
In any case, I did answer your question - you can achieve the same level of minimalism by using linked lists, and yes, OOP in C. Shouldn't be exactly news to anyone who has learned C (not that difficult anyway).
I don't see any compelling reasons to choose a stackbased API over anything else.
I've found myself figuratively battling with Lua when I tried to create nontrivial objects, such as metatables with constructors, indices, missing indices handling, etc, you name it. It's fun and easy for small things, but gets cumbersome really quick. And inline-evaluating Lua code just because the API has been updated in some odd ways, so that previously perfectly fine working code now compiles, but no longer works, just feels hacky to the max.
With a non-stackbased API, this is literally just a matter of walking function calls (the native program stack). But with a stackbased API, you have to walk the machine stack AND the API stack.
That's not fun. Not even remotely. This is how you teach a programmer to hate programming.
The grand majority of programming language APIs do not use a stack-based API. Really, stack-based APIs are an exception in just about every way, but not in a good way.
It makes a great deal of sense, especially when dealing with an interpreter for a stack-like machine, to expose language bindings in terms of that stack.
It's not super friendly, mind, but it makes perfect sense.
1.50$ for an entire pack of USB sticks? Where did you find such an offer? Because according to amazon, the cheapest they have are a pack of 10 USB sticks, 1GB, for 39$:
Not exactly cheap, if you ask me. Not exactly super-expensive either, of course, but definitely not cheap. And I think the reasons the price for floppy disks doesn't seem to go down is because only certain people still use floppy disks, i.e., the need for floppy disks is nearly non-existant.
Amazon is virtually never the best price on items <$5. They carry very, very few items in that price range outside their "addon" program (items that only ship with $25+ in other goods) -- what you linked is an ad for a product sold by another store.
eBay, Alibaba, or contacting the wholesale division of any of the stores you get searching "bulk flash drive" on Google would be a better idea. They start around $2.50/drive retail with your logo custom printed, so you can do much better wholesale.
>Can you elaborate on why you feel a need for such physical media?
Maybe it's not perceived the same way in the USA, but in Europe, most people who use cloud-services find it increasingly difficult to trust american cloud-services, thanks to the NSA. Hence why I'm looking for alternative ways to share sensitive information, programs, documents, you name it.
There's of course also owncloud, which is nice enough, but let's just assume that some may not even have access to the internet in the first place.
So, with respect to the point you made (make no mistake, it's a very good point), I say that there are scenarios that justify need for physical mediums to share data.
I'm in Europe (Sweden), and while a lot of people on HN and in the tech community care, most other people I know here just don't have this on their top 100 list of things they worry about.
That said, I agree that sensitive or not, we really shouldn't be sharing everything over only a handful of communication channels (typically home & work broadband connection + mobile phone data connection). It makes surveillance all too easy.
This is where I think smart people could make a difference. When I want to share data with someone in the same location as me we should really be talking P2P only. It wouldn't allow NSA & co to get the same full picture as easy as they can now with central data hubs and only a few communication channels.
I'm from Germany, so I see what you mean -- in Europe, especially central and northern europe, there's hardly any need to share files physically. But alternatives are necessary in times like these, which is why I'm glad things like P2P-services exist.
I guess you could say I'm merely planning for the future. Not that I wish that I'd ever actually have to go about sharing data via physical mediums, but I wouldn't exactly bet on it.
