I think it is wise to publicly announce both speakers who have accepted invitations and speakers whose invitations were revoked (don't even have to say they are revoked, simply stating "unfortunately John Doe will not be speaking in our conf" should be sufficient). If not for these situations, then simply to inform visitors whom they can expect to hear in the conference.
> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).
There is no way for you to mess up something at the other end of your web app if you use specific sass files for specific web pages. The 'basket' class can be defined as one thing on the page for selling baskets, and it can be defined completely differently on some other page where baskets are, idk, displayed in some other way.
Please elaborate. I don't see how having a library of SASS mixins that you mix in to make specific CSS classes for specific purposes make anything harder to manage? If anything, decomposing things to smallest common denominator makes it easier to build better and more versatile CSS for your apps.
It's not the sass mixins that makes things harder to manage. The problem is having nested CSS rules that cause your CSS to become tightly coupled to the structure of HTML. Then when the HTML changes, you have to rethink the relationships. And if you're not using nesting, then isn't what you described just utility classes abstracted one level away?
Qt is LGPL. So there are no limitations unless you make changes to the Qt library (which you probably won't do). If you do make changes, though, then you would have to release them under LGPL license.
So, I think there are absolutely no limitations to using Qt LGPL in a commercial application. All you get from the commercial license is support.
Note: I'm not a lawyer, don't hang me if you get sued or something. But I do think I'm right about this.
> there are no limitations unless you make changes to the Qt library
I thought you were required to allow linking to a newer or modified version of a LGPL library? So one limitation is you have to either dynamically link or provide a mechanism to relink.
IANAL, but this requirement is the reason I stopped using Qt for my own projects. Those terms would seem to mean anything you write using Qt can't be deployed on a closed platform. Tons of people use LGPLd code on iOS and Android (stores like Play and Amazon) though and I think most users and developers are ignorant of the relinking requirement. I didn't want to risk it.
The Apache Software Foundation does not allow its projects to have mandatory LGPL dependencies for this reason: it would become impossible to bundle the Apache product plus its dependencies into a package that forbids modification, either through technical or licensing restrictions.
This linking restriction is not a part of other product-scoped copyleft licenses like the MPL and the EPL.
Google has now killed off Sparrow entirely, but they used to make it available for download so that an end-user could in principle re-link it, to comply with the LGPL.
So if I were to statically link my application but release the object files and let user's re-compile it with another version of the library then that would satisfy the LGPL license? If so I think I might be headed back to Qt.
Yes, if you link dynamically, you are generally okay with just sending your executables.
If you link statically, you also have to make your object code available for relinking if needed. But that generally comes down to doing something like "ar q libMyApp.a *.o" and then the user would make the app with "gcc -o MyApp libMyApp.a -lQtWhatever".
If you distribute as some package (like .apk for android), you'd have to make it possible for user to change the library. Simply allowing users to download .apk files would make it work, since they can unzip them, change the library and rezip them back.
So, I wouldn't really call those "limitations". Just pesky things you have to do if making a commercial app with lgpl lib.
Oh, and there is no requirement to link with a newer version of the library, to the best of my knowledge. That's generally impossible since newer versions might (and do) deprecate features that were available in the older versions.
It's also in the meantime LGPLv3 - at least for certain QT components, but the system is not easy to understand. The v3 requirements add that if you distribute an application (or device) with it, you have to provide the user with a way to update the linked QT library with a different version that he provides himself.
Well, why not then say this is domain registrar's fault, since somebody clearly did allow registration of paypal.com.tk or something similar.
SSL certificate is for secure communication with some website. Whether the website is a malicious one or not has absolutely nothing to do with security of the communication with said site.
I think the problem here is that people believe sites which are SSL enabled are good, and that problem will be fixed when all the web sites become SSL enabled.
cppreference.com usually has [c++XYZ] marks on features introduced by a specific version of C++ and it is usually current with updates while having some basic examples for most things. The site doesn't have a comprehensive list of all the features introduced in the specific version of C++, but which ever feature is interesting to you should be easy to find there.
The extension needs to be reviewed by Mozilla and signed unfortunately. 80% get done within 5 days but unclear if this will be the case here. Meanwhile you can use the bookmarklets at https://ctxt.io/faq but those won't work on CORS/CSP restricted sites.
Well, imagine being able to project your "laptop" where ever you want using AR? Then you could use it as your home desktop-laptop and carry it everywhere with you.
Tablets are cool and you can carry them everywhere, but you can't really work important stuff on them since they are still too small.
On the other hand, even if laptops had very good battery life (which usually is not the case), they are still too big and heavy to carry around unless really needed (ie. for a meeting or something like that).
But an augmented reality laptop that lives in your phone is something people might want to use. Not for gaming, but for normal office work, be it programming or using spreadsheets.
And, at that point, regular users might think about obsoleting desktop PCs and laptops.
A projected AR display would only be useful for creative and business work if it can completely occlude the background. I won't be able to see the spreadsheet clearly if light leaks through it through from the window in front of me. Due to limits imposed by optics, complete background light blockage is always going to require a bulky, awkward head-mounted display. No one has proposed any way to get around this issue even in theory.
Well, you can always project the virtual laptop's screen on a pizza box or a wall or something like that. But I agree in general. I'd prefer a foldable laptop, but I doubt the technology for something like that is anywhere near, while this AR laptop could be made tomorrow. There already are virtual machines made for mobile phones, all that is left is connecting them to AR glasses and voila.
Walls and pizza boxes aren't sufficiently smooth or reflective to use as projection screens for real work. An AR laptop couldn't be made tomorrow because the glasses exist only in limited prototype form with poor display quality.
I believe ctxt.io requires Chrome extension to work properly. It does seam like a good method for sharing web pages, but, as I too use Firefox, not the thing for me (for now).
