I'm not sure where you misunderstood me. I said "virtual frame buffer" and VNC. The virtual frame buffer is a software-only framebuffer, separate from the one that drives the screen. It can have anything on it - simplified UI controls, or rather, with android, you would add settings to the app manifest to specify it uses that VFB and people would lay out for in-car use accordingly.
The automobile is a challenging acoustic environment for sure, but there are several improvements that can be made to improve this: A unidirectional mic in the steering wheel, with noise cancelling. A prompt button that turns down the stereo system for a brief time.
I'm not surprised it is as bad as it is with current equipment. In fact I'm surprised it is as good as it is.
The tactile controls are there for cost. Very cheap, but very limiting. I have proper climate control that maintains a set point, and I never have to touch anything more than a defroster button. In fact the only button I touch frequently is the stereo knob.
How complicated of gestures do you need on a screen while driving? As far as I am concerned it should all be voice interface anyway. As someone who uses a docked phone while driving (or rather attempts to) the bumps in the road combined with the reach distance conspire against virtual buttons due to lack of tactile feedback. You can't feel for the 3rd button down, or if you landed your finger on the gap between two buttons.
Each mobile platform (iOS, Android, WP?) should just have a virtual frame buffer which is connected to via VNC. There's not any reason to make it more integrated than that, unless they try to differentiate themselves, and in that case we all lose because of fractured standards. I really cringe when Google and Apple don;t back the same standard.
We're not going to come to any absolute decision or agreement. Which is fine. The world and morals aren't experienced in terms of absolutes.
It depends on what "weapon" means. An amalgamation of steel resembling an AK-47 is a weapon. Heck even a chunk of iron ore is a weapon. It's not the weapon that is bad it is the use. And weapons and software are used in both moral and amoral contexts. It's not the lines of code or parts of the machine. It becomes moral only when a person picks it up and carries out their intent.
By applying a morality clause, I limit the intents that the software can be used in. Importantly, I create a barrier to entry as someone would have to recreate the software to accomplish an intent. This additional effort is then is a signal of software with a malicious intent. It would allow us to ask the questions of "Why can't this software use a moral license?" Maybe it is decided that the intent is valid, and immoral software should be used because the intent is that important. But we would know it. The current state of OSS licenses makes no distinction.
Finally, as you point out "people with weapons cause suffering and need to be stopped by other people with weapons". The US has supported various rebel groups who were allies, only to have them turn around and become enemies or terrorist groups. What gets accomplished there is just killing... on both sides. One has to question if these behaviors that lead to killing on both sides is a smart idea. The idea here are allegiances are fleeting, death is permanent.
Fundamentally, I want my work or portion of my work to be used in killing someone. I'm sure there are others. And I'm not entirely a pacifist. I just want to limit the applications of my open source work to moral causes.
I would counter with morality is not religion. And religion is not morality.
The first tier of morality, as far as the moral operable software license is concerned, it is akin to Asimov's Laws of Robotics. Since robotics will most likely consist of a software component, the software itself should be covered by a license with morality clause.
I would then say the second tier is to not cause non-lethal suffering. This would include things like torture (physical), torture (mental), causing injury, disease and malnutrition.
The third and final tier would be socioeconomic suffering. It would not create artificially limiting factors when those factors are not a choice. (Sex, race, etc)
After that, there is plenty of potential for immoral software. The goal isn't to create perfectly moral software (hell it's hard enough to make software that work as intended regardless of morality) but it is to assure developers and users that the software will only be used to advance humanity in the broad sense.
We gotta start with the biggest apps first. Then move on to the AutoCADs. If Adobe moved, then the single largest publisher of software outside the OS vendors (by user) would make people notice. Then we'd get a bigger install base that would snowball to the next biggest, etc, etc. so that Linux was it's own platform.
As a Mint 16/17 user that occasionally deals with Win 8: - Updates - The distro has a unified updater. That updates in the background. Not at boot up, not at shutdown. No forced reboots by the updater. No waiting. - Metro (user learning curve) - and an overall respect for you. I get the feeling I'm a market, a commodity when on Windows. Told to install all this crapware, slogged aroudn with the latest trends. I just want to work, or kill time under my terms. If you need firm example, MS forcing MSN Messenger over to Skype. All the various virus scanners and viruses. I love being immune to all those web hacks.
I use Mint 17 Linux daily, but what I miss, what is really lacking are Adobe apps. Someone should start a kickstarter for Linux ports. Adobe is already familiar with Qt ( I think I read Lightroom is Qt) so they have the experience.
Let's put our money where our mouth is and get adobe to Kickstart the ports.
That would be fine. If I imposed such a restriction, someone can come along and invent separate software a less restrictive license, which is completely within their right.
I'm on a mobile team and iOS and Android are a lot less similar than you would think. There are few constructs shared between the two. This isn't Qt's problem.
It's not a popularity contest. It's about our legacy as human beings and as open source is inherently collective, our collective coding effort being a moral and just one. While I would like the license to be popular, only in so much that I can be assured that the software is being used to advance humanity, not to stifle it. As well as contributors to the projects can rest assured the code they submit would never be used against themselves or others in an immoral fashion.
You, of course, are free to choose an immoral license.
If that is so, then I find it abhorrent that the OSS movement prioritizes the freedoms of killing, censorship and persecution above the right to life and live.
So what you're saying is we could have an OSS licensed SkyNet? "It's ok because it's GPL!" Riiiiiiiiiiiiight.
I'm on board with OSS. But I don't think it goes far enough. The right to modify the code you run is a good one. But I am calling for OSS licenses to pick up another clause, the Zero-Kill clause, where in using the software in any weapons platform (be it sniper rifles or predator drones) is forbidden. People should have the right to not fear being killed by open source software.
Additionally, I am calling for another clause to protect human rights. People should be free from fear that OSS will be used to restrict their freedoms in other ways. This includes forbidding use of the software for censorship or oppression.
There's some savings to be had by, if you have a geographically distributed system across time zones, moving loads to lower commercial rates based on time zone.
For those that don't know, commercial rates vary, and spike at peak demand time (~14:00) Moving peak load by forward or back 2 time zones would move you out of peak rates.
I started out all full of piss and vinegar and eventually learned to relax.
You will only make enemies if you play politics. Only play in politics that involve you directly. Let everything else go. It's not your job to know it though you have the ability to. You won't be faulted for not disclosing something that your privileges allowed you to know, but declined to know.
Be everyone's friend. I made friends and gained people's trust by being fair. They told me even more. I could go around uninstalling their games and stuff... But I didn't because it's just piss them off. So I just told them I saw the game and if something starts behaving weirdly, I'm going to blame the game first, and that they should uninstall it before I came back. That seemed to be enough to cover my ass in the event someone else found it and reported it to the head of IT. It kept me from making enemies. Exercising restraint is the key to success. If no one likes you, they won't put in the good word.
Problem: browsers only run JS, which has it's virtues and warts. Solution: have a plug-in scripting engine where you can use any language, and let the developers choose their set of virtues and warts.
There is no reason why we can't develop a plugin interface, and have other languages up and working in short order. Python would be great. Just include.py file instead of.js and have that in the interpreter. With a common shared DOM object, you can keep existing JS and transition to your language of choice.
The Android SDK/platform sucks big donkey dongles. I won't get into why here. But I'm an android developer and out of everything I've learned it is the worst.
At least with Qt you can write apps for every major platform, desktop or mobile. What I've done with it (successfully) is develop apps using my desktop, then add the tool chain for mobile compiler, and compile for that platform. That way, the toolkit becomes the simulator and you don't need to run your app though an emulator or simulator, which saves a surprising amount of time!
For example, using Qt, I've successfully used the camera API transparently on Linux and Android and Windows. What I mean by that is I developed a camera-using app on Linux, ran it on the phone, then ran it on windows 7, without changing the source code at all.
As far as I am concerned, no one should actually be using the Android SDK except those trivially simple apps. At best they are inferior (Activity and fragment lifecycle management is horrible), the SDKs themselves are not written using best Java practices, they lock you in to that platform (Can't run the same app on iOS and Android... or desktop).
Google is barking up the wrong tree. It's not that the web or the languages are flawed, it's that the serialization to HTML and JS and CSS is flawed.
There is no [big] reason why we can't drop the data serialization and program directly against webkit objects. Once you can manipulate webkit directly, you can do so from any language. It's only because we've locked ourselves in to the textual serialization of varying interpretations that we have the clusterfuck of today. Rather than interacting through a DOM, we could jsut provide the objects themsleves. Think if it this way, really just does: ti = new TextInput(); ti.setName("name")... The structure of these objects is organized in the DOM, which gives a parent-child relationship. We can get rid of the DOM as a serialized format and just link the objects together accordingly.
Think of it like this, when a web client talks to a web server they just have a textual interface open to various interpretations. With the object interface I describe, the client provides access to objects which are directly manipulated by the server. There is no ambiguity, aside from how the object is implemented in the client. In this way, someone can code for any implementation in perfect specificity, with only the assumption that the instantiated object behaves in accordance to the behavior spec. There is no reason the program code on the server cannot be stored on the client, however this is just user-interface client code.
While in HS, the school's rock band, QP (Quater Pound) wanted special effects for their performances. With some of us AV geeks, we got an early data projector (LCD screen that went on a overlay projector) and me and another guy wrote a program in QBASIC to rotate and scale a pot leaf (1bpp bitmap, converted to a list a vertices - by software we also wrote) using a ASM library based on the values of the SoundBlaster 16 card. Some of the programming was done while drunk, of course.
Slashdot Mirror
I'm not sure where you misunderstood me. I said "virtual frame buffer" and VNC. The virtual frame buffer is a software-only framebuffer, separate from the one that drives the screen. It can have anything on it - simplified UI controls, or rather, with android, you would add settings to the app manifest to specify it uses that VFB and people would lay out for in-car use accordingly.
The automobile is a challenging acoustic environment for sure, but there are several improvements that can be made to improve this:
A unidirectional mic in the steering wheel, with noise cancelling. A prompt button that turns down the stereo system for a brief time.
I'm not surprised it is as bad as it is with current equipment. In fact I'm surprised it is as good as it is.
The tactile controls are there for cost. Very cheap, but very limiting. I have proper climate control that maintains a set point, and I never have to touch anything more than a defroster button. In fact the only button I touch frequently is the stereo knob.
I don't see why it shouldn't.
How complicated of gestures do you need on a screen while driving? As far as I am concerned it should all be voice interface anyway. As someone who uses a docked phone while driving (or rather attempts to) the bumps in the road combined with the reach distance conspire against virtual buttons due to lack of tactile feedback. You can't feel for the 3rd button down, or if you landed your finger on the gap between two buttons.
Each mobile platform (iOS, Android, WP?) should just have a virtual frame buffer which is connected to via VNC. There's not any reason to make it more integrated than that, unless they try to differentiate themselves, and in that case we all lose because of fractured standards. I really cringe when Google and Apple don;t back the same standard.
If you need audio, use Bluetooth, of course.
We're not going to come to any absolute decision or agreement. Which is fine. The world and morals aren't experienced in terms of absolutes.
It depends on what "weapon" means. An amalgamation of steel resembling an AK-47 is a weapon. Heck even a chunk of iron ore is a weapon. It's not the weapon that is bad it is the use. And weapons and software are used in both moral and amoral contexts. It's not the lines of code or parts of the machine. It becomes moral only when a person picks it up and carries out their intent.
By applying a morality clause, I limit the intents that the software can be used in. Importantly, I create a barrier to entry as someone would have to recreate the software to accomplish an intent. This additional effort is then is a signal of software with a malicious intent. It would allow us to ask the questions of "Why can't this software use a moral license?" Maybe it is decided that the intent is valid, and immoral software should be used because the intent is that important. But we would know it. The current state of OSS licenses makes no distinction.
Finally, as you point out "people with weapons cause suffering and need to be stopped by other people with weapons". The US has supported various rebel groups who were allies, only to have them turn around and become enemies or terrorist groups. What gets accomplished there is just killing... on both sides. One has to question if these behaviors that lead to killing on both sides is a smart idea. The idea here are allegiances are fleeting, death is permanent.
Fundamentally, I want my work or portion of my work to be used in killing someone. I'm sure there are others. And I'm not entirely a pacifist. I just want to limit the applications of my open source work to moral causes.
I would counter with morality is not religion. And religion is not morality.
The first tier of morality, as far as the moral operable software license is concerned, it is akin to Asimov's Laws of Robotics. Since robotics will most likely consist of a software component, the software itself should be covered by a license with morality clause.
I would then say the second tier is to not cause non-lethal suffering. This would include things like torture (physical), torture (mental), causing injury, disease and malnutrition.
The third and final tier would be socioeconomic suffering. It would not create artificially limiting factors when those factors are not a choice. (Sex, race, etc)
After that, there is plenty of potential for immoral software. The goal isn't to create perfectly moral software (hell it's hard enough to make software that work as intended regardless of morality) but it is to assure developers and users that the software will only be used to advance humanity in the broad sense.
We gotta start with the biggest apps first. Then move on to the AutoCADs. If Adobe moved, then the single largest publisher of software outside the OS vendors (by user) would make people notice. Then we'd get a bigger install base that would snowball to the next biggest, etc, etc. so that Linux was it's own platform.
As a Mint 16/17 user that occasionally deals with Win 8:
- Updates - The distro has a unified updater. That updates in the background. Not at boot up, not at shutdown. No forced reboots by the updater. No waiting.
- Metro (user learning curve)
- and an overall respect for you. I get the feeling I'm a market, a commodity when on Windows. Told to install all this crapware, slogged aroudn with the latest trends. I just want to work, or kill time under my terms. If you need firm example, MS forcing MSN Messenger over to Skype. All the various virus scanners and viruses. I love being immune to all those web hacks.
I've transitioned a 65 year old man (neighbor) and my 30-something sister to Mint 17 Cinnamon. Both have zero issues after I switched them from XP.
I use Mint 17 Linux daily, but what I miss, what is really lacking are Adobe apps. Someone should start a kickstarter for Linux ports. Adobe is already familiar with Qt ( I think I read Lightroom is Qt) so they have the experience.
Let's put our money where our mouth is and get adobe to Kickstart the ports.
We'll win it when it is irrelevant.
That would be fine. If I imposed such a restriction, someone can come along and invent separate software a less restrictive license, which is completely within their right.
Um what?
I'm on a mobile team and iOS and Android are a lot less similar than you would think. There are few constructs shared between the two. This isn't Qt's problem.
It's not a popularity contest. It's about our legacy as human beings and as open source is inherently collective, our collective coding effort being a moral and just one.
While I would like the license to be popular, only in so much that I can be assured that the software is being used to advance humanity, not to stifle it. As well as contributors to the projects can rest assured the code they submit would never be used against themselves or others in an immoral fashion.
You, of course, are free to choose an immoral license.
If that is so, then I find it abhorrent that the OSS movement prioritizes the freedoms of killing, censorship and persecution above the right to life and live.
So what you're saying is we could have an OSS licensed SkyNet? "It's ok because it's GPL!" Riiiiiiiiiiiiight.
I'm on board with OSS. But I don't think it goes far enough. The right to modify the code you run is a good one. But I am calling for OSS licenses to pick up another clause, the Zero-Kill clause, where in using the software in any weapons platform (be it sniper rifles or predator drones) is forbidden. People should have the right to not fear being killed by open source software.
Additionally, I am calling for another clause to protect human rights. People should be free from fear that OSS will be used to restrict their freedoms in other ways. This includes forbidding use of the software for censorship or oppression.
There's some savings to be had by, if you have a geographically distributed system across time zones, moving loads to lower commercial rates based on time zone.
For those that don't know, commercial rates vary, and spike at peak demand time (~14:00) Moving peak load by forward or back 2 time zones would move you out of peak rates.
I started out all full of piss and vinegar and eventually learned to relax.
You will only make enemies if you play politics. Only play in politics that involve you directly. Let everything else go. It's not your job to know it though you have the ability to. You won't be faulted for not disclosing something that your privileges allowed you to know, but declined to know.
Be everyone's friend. I made friends and gained people's trust by being fair. They told me even more. I could go around uninstalling their games and stuff... But I didn't because it's just piss them off. So I just told them I saw the game and if something starts behaving weirdly, I'm going to blame the game first, and that they should uninstall it before I came back. That seemed to be enough to cover my ass in the event someone else found it and reported it to the head of IT. It kept me from making enemies. Exercising restraint is the key to success. If no one likes you, they won't put in the good word.
The problem isn't in the upstream, it's in the downstream. Specifically their L3 interconnects.
new-boss-same-as-the-old-boss overlords!
(That's the forecast anyway)
I know what's down there
Problem: browsers only run JS, which has it's virtues and warts.
Solution: have a plug-in scripting engine where you can use any language, and let the developers choose their set of virtues and warts.
There is no reason why we can't develop a plugin interface, and have other languages up and working in short order. Python would be great. Just include .py file instead of .js and have that in the interpreter. With a common shared DOM object, you can keep existing JS and transition to your language of choice.
The Android SDK/platform sucks big donkey dongles. I won't get into why here. But I'm an android developer and out of everything I've learned it is the worst.
At least with Qt you can write apps for every major platform, desktop or mobile. What I've done with it (successfully) is develop apps using my desktop, then add the tool chain for mobile compiler, and compile for that platform. That way, the toolkit becomes the simulator and you don't need to run your app though an emulator or simulator, which saves a surprising amount of time!
For example, using Qt, I've successfully used the camera API transparently on Linux and Android and Windows. What I mean by that is I developed a camera-using app on Linux, ran it on the phone, then ran it on windows 7, without changing the source code at all.
As far as I am concerned, no one should actually be using the Android SDK except those trivially simple apps. At best they are inferior (Activity and fragment lifecycle management is horrible), the SDKs themselves are not written using best Java practices, they lock you in to that platform (Can't run the same app on iOS and Android... or desktop).
Google is barking up the wrong tree. It's not that the web or the languages are flawed, it's that the serialization to HTML and JS and CSS is flawed.
There is no [big] reason why we can't drop the data serialization and program directly against webkit objects. Once you can manipulate webkit directly, you can do so from any language. It's only because we've locked ourselves in to the textual serialization of varying interpretations that we have the clusterfuck of today. Rather than interacting through a DOM, we could jsut provide the objects themsleves. Think if it this way, really just does: ti = new TextInput(); ti.setName("name")... The structure of these objects is organized in the DOM, which gives a parent-child relationship. We can get rid of the DOM as a serialized format and just link the objects together accordingly.
Think of it like this, when a web client talks to a web server they just have a textual interface open to various interpretations. With the object interface I describe, the client provides access to objects which are directly manipulated by the server. There is no ambiguity, aside from how the object is implemented in the client. In this way, someone can code for any implementation in perfect specificity, with only the assumption that the instantiated object behaves in accordance to the behavior spec. There is no reason the program code on the server cannot be stored on the client, however this is just user-interface client code.
While in HS, the school's rock band, QP (Quater Pound) wanted special effects for their performances. With some of us AV geeks, we got an early data projector (LCD screen that went on a overlay projector) and me and another guy wrote a program in QBASIC to rotate and scale a pot leaf (1bpp bitmap, converted to a list a vertices - by software we also wrote) using a ASM library based on the values of the SoundBlaster 16 card. Some of the programming was done while drunk, of course.