Microblog
in reply to @ 2015-324 03:26 UTCThis is the model companies like withknown.com use
in reply to @ 2015-324 03:21 UTCWell, basically the way it works is that you charge people to use the service. Then you offer to anyone who is a user access to the source code under a free license.
in reply to @ 2015-323 16:45 UTCI would simply charge people for using the service if they felt it will be useful to them
This model is still perfectly acceptable for freedom-respecting software
in reply to @ 2015-323 13:48 UTCi.MX6 systems like the Hummingboard aren't even listed
in reply to @ 2015-323 01:37 UTCnitrokey
in reply to @ 2015-323 00:42 UTCffmpeg will do pretty much anything to anything 🙂
in reply to @ 2015-322 23:29 UTCThe author seems completely disconnected from the average museum visitor. If the photos do not harm the content and visitors find they enhance their experience, then what is the problem? That you personally dislike their photos? No one is making you look at their photos.
in reply to @ 2015-322 20:29 UTCFrom
https://d.wifo.org/t/places-to-find-commons-news-and-new-works-projects/162:
in reply to @ 2015-320 18:38 UTC
The constraints for Monad code using fail become (Monad m, ApplicativeFail m) => instead of the simpler MonadFail m =>. If we expect the common use of fail to be in Monad — not Applicative — do-notation, this leaves us with more verbose constraints.
Why is this a problem? Having multiple constraints when using multiple features is a normal and useful feature of Haskell.
in reply to @ 2015-320 18:32 UTCIf I have
MonadFail
andApplicative
defined and use ApplicativeDo, will it use myfail
even if my context is notMonad
?