It *is* however of interest to persons wanting to either hire the elusive genius, or pick his brains on other complex algorithmical topics over an extended interview.
I wonder if there are any, against all wisdom, control posts for nuclear facilities that are running Windows 7 or 8, that really, cannot, must not, be interrupted during sensitive operations.
This strikes me not so much about studying "free will" than our inability to operate on extremely small timescales.
Second of all, I would be very reticent to accept into general principle the idea that there is no free will.)
If free will is an an illusion, then so be it (and I will have been fated to deny such a reality anyway, so stop bugging me)
But if free will is in fact reality, we have two main choices
We can choose to assert that free will exists, and continue exercising it
We can choose to assert that free will is indeed an illusion, and give up any sense of responsibility -- corollary to this is absolving an agent of any behaviour or action as being "destiny," and using this to explain away, and sometimes justify, all sorts of unpalatable or unethical behaviour.
If free will exists but we assert it does not, we surrender it of our own volition: if there is hope, but we do not keep hope, then from our own decision, there is no longer hope.
If you're using a LAMP stack mainly (which it seems you are), the option of SSH and using a command line text editor could be of interest.
That being said, if you can create a dev environment that matches your production, why not git around? Where has this workflow failed you previously? Surely also you are developing on multiple servers for different projects, and there are things you do common to all servers?
For my sites I use generally two git repos - one for my toolchain (custom connection, management and setup scripts), one for base content. Given that I use Wordpress for a lot, I can duplicate some of the base work. I use digitalOcean, always a ubuntu 14.04 server, and always set up with the same scripts. I do have a test VM directly on my machine to test things that might seriously break stuff, or for dev when I'm on the go without network, but otherwise, a lot of what I do is "in the cloud" - just over SSH.
As to how this would map to your requirements:
1) No syncing hassles across machines
If you're a team of one, SSH+cli editor should work - it's also lower processing power on your device. Better battery longevity. You can also quickly move back and forth between server logs and code from here too
2) No installation of toolchains to get working or back to work — a browser and a connection is all that would be required
Unless I'm mistaken, you'll always have toolchains to install and update on every new site/server. So long as you maintain an easy way to deploy them fresh, and the new instances you spin up are always predictably similar, I see no problem with maintaining a toolchain deployment recipe in one place, and easily management of instances along the way in teh way you want (ansible, chef, puppet, custom scripts...).
3) Easy teamwork
If the solution you want is for live coolaborative editing, maybe indeed a web-interface which facilitates this may be interesting, though you'll want to check that this mode of "team" working suites your team best, or if revision control-based solution works better for their workflows. Maybe a question for the web-based solution is, does it integrate well with individuals who like to work offline and sync as needed? I'll assume you've already had this talk with them.
4) Easy deployment
I'd say this is down to DRY - Don't Repeat Yourself, or, have you automated everything you could have?:-)
5) A move to Chrome OS for ultra-cheap laptop goodness would become realistic.
That's a personal preference I guess. I wouldn't try it just yet. I try to run a lean machine, but I like to know I Have The Power when I need it.
At the end of the day, so long as you have revision control in whatever solution you choose, you have a decent chance of developing on production. Now about the databases...
1/ The Mythical Man Month was "referenced" (and mangled) about in an unrelated article by Eddy Baldry. It is he who mis-states the premise of the MMM
2/ Mythical Man Month's statement is "Adding more manpower to an already late project delays it further." This is different from the premise stated by Baldry.
3/ Anders Wallgren mentions nothing of the Mythical Man Month
4/ Wallgren actually does say that microservices, underpinning some of the arguments for DevOps, is not suitaed for all projects.
And I'm gonna say it - why not use disk-encrypted Linux and put Windows in a VM for those one or two programs that are Windows-only? This way you have full control of your system, the whole disk is encrypted, and you can stick to Windows 7...
So two thoughts come to me after reading the summary and the comments
1/ This clearly demonstrates that Linux is the right technology to use when supporting business syetms with legacy hardware (I'll second the opinions that enterprise keeps hardware around the longest - I supported users on obsolete AS/400s which, whilst not as old as what some people here talk about, still mean we're frequently learning old technology in Support); and the point that the leadership (Linus right now, hopefully the same with whomever comes to replace him eventually!) can be more ameanable to keeping up support for old hardware is great. I dream of desktop uptake, but enterprise and research are where it's at.
2/ However I also wonder - isn't this an offshoot problem of the fact that Linux is a monolothic kernel? Can this kind of interface-specific support not be modularized? Say, an API/ABI (in-kernel)standard that allows the kernel to plough on with currently evolving requirements, whilst maintaining a stable interface for previously integrated kernel features that have been split off into modules...?
(and no, I'm not at all familiar with the ins and outs of kernel development and architecture - I just read newsposts and Wikipedia...)
So the major players want to bring some order to the bazaar. So be it - they can try. There are small projects that will probably decide to cooperate, and will because they are a one- or two- person effort - but the projects that truly behave like a bazaar will remain as coordinated or uncoordinated as they still are.
I don't see this effort being capable of shoving an agenda down anybody's throats - if you don't care for the agenda, don't. Submit your code to the project as and when you see fit, and work on the bits you want to. If tomorrow they want to address what they see as glaring issues in GNU's netcat, they'll be able to throw resources at it collectively - but I doubt they'll be able to tap GNU's shoulder and say "hey, give us some of 'your' devs to fix this."
In the end, if the effort results in a pooled selection of developers, incentivized directly and collectively (read: employed) by the companies, to work on aspects of open source projects they have communal stake in, to common goals and specification, that is probably going to be a good thing.
If they fork any of the technologies that is fine too - that's exactly what GNU GPLv3 was meant to allow them to do. They just can't expect to fork the maintainers and community too.
If however there is a scenario in which volunteers can be coerced into their way or the highway, that scenario must be understood and countermeasures prepared by those who would stand to lose from it. Don't take it too seriously, but don't take it in any way lightly either.
The "highly restricted" spec is meant to catch suspicious combos like in the mybank example - but does not catch full-ascii (which is an even more restrictive level) trickery like tvvitter.com (notice the two "v" chars). that combo in particular is now known, but goes to demonstrate that trickery does not need charsets larger than 7-bit... some people simply get caught by hsbc.net...
In the original article an ArretSurImages.fr, the blogger details in her interview that she decided not to hire a lawyer, instead simply complied immediately and did not defend her position. She was not required by the court to remove her post, but she did so of her own accord.
A commenting lawyer interviewed for the article indicated that the case shows more the necessity of getting legal advice, rather than any evolution of rights on the Internet.
Yes it's sad that she was attacked for her criticisms, but it's sadder that she did not take responsibility, or stand her ground.
Hm. I would say "there goes my preference for not associating my phone with an online account" but that would actually be incorrect. Though I would indeed prefer not to have to have an account to install apps.
I guess I still treat my phone like a computer in many respects and I'm trying my darndest to keep it away from any form of remote kill at all for the sake of a "no remote please" blanket stance...
Still, I'm pretty sure I prefer to be slightly on the neurotic side.
Whilst all this may be valid and true, how are we going to prevent the "wrong people" from using this kill switch? Will it be hardware based, in which case, how will we be sure it won't be triggered/used remotely if we install a different OS on the device? Or if some script kiddie found a way of activating it by exploiting an insecure app?
(new hollywood armaggedon scenario: terrorists threaten to detonante a phone bomb that would activate kill switches around the world, bringing down entire civilizations)
Yes, a technological solution might exist for the problem; question is, is this one the right one? Are we going to stop looking for alternatives?
Reading the original article on Les Echos.fr, it seems to me this is not law but an agreement between a coalition of enterprise owners and the unions - they've signed an agreement to implement this.
La semaine dernière, après six mois de négociation, le patronat des sociétés d’ingénierie et de conseil et des bureaux d’études (Syntec et Cinov) a signé avec la CFDT et la CGC (56% de leurs salariés à elles deux) un avenant à l’accord de 1999 sur les 35 heures qui pourrait avoir valeur d’exemple.
"Last week, after six months of negotiation, [ a union of ] bosses of engineering, consulting and design departments (Syntec and Cinov) signed with CFDT and CGC [workers' unions] (56% of their joint workforce) an ammendment to the 1999 agreement on the right to 35 hour working week which could set an example [to the rest of the country?]."
A third union that didn't sign, the CGT, is actually deploring the fact that it still has a loophole allowing it to be ignored, and a previous agreement between the two camps to try and improve working conditions was struck down by a court of law:
Cela suffira-t-il à convaincre les juges? L’avenant est un nouvel épisode du feuilleton juridique, que les signataires espèrent être le dernier dans leur profession. En avril 2013, la Cour de cassation avait invalidé le précédent dispositif, jugeant le contrôle de l’amplitude et de la charge de travail insuffisant.
Will it be enough to convince the judges? The amendment is a new episode in this jurisdiction saga, which the signatories hope to be the last in their profession. In April 2013, a high court rejected their last attempt, judging that the control of the amplitude and amount of work insufficient.
French journalistic style is not as easy to decipher as English-language journalism -- the French style is very fond of appearing as literary as possible. I'll post extra translations at some point if anybody wants.
Anybody who has tried to put a bog-standard user on Free Software Only laptops (Yeelong or X60 exclusively) with only Free Software and no proprietary.... knows that the user runs screaming back to the motherly proprietary vendors with reinforced assurance that the FSF are nuts. And we all lose.
If the advice you gave was too difficult to follow, you didn't take your audience into account. / If the advice they need requires extra knowedge/effort, be there to help them implement.
On the whole however I think the idea is spot on. Could do with some <h1> and <h2> lines to help the TL;DR crowd.
TDF should be pushing their scriptable LibreOffice, and point out the benefits of not having to purchase it either now or in the future, the freedom of open formats, and also the benefits from a "smart kids" point of view to giving them an open-sourced office suite they can tinker with.
If companies see value in using Microsoft's full suite and stack, more power to them both. In the mean time, from an educational, budget and general open formats point of view, LibreOffice is the way to go.
Heck, if it's about kids' programming skills, and if the kids think they can improve the scriptability of the application itself, they could even submit their own patches and features to LO. Not so with MSO.
Slashdot Mirror
.... wondering why there wasn't a direct link in the Canonical blog but hey ho
Web Browser: Firefox ...)
Email Client: ???
Terminal: GNOME Terminal. Maybe guake.
IDE: Geany
File manager: ???
Basic Text Editor: gedit (vim really, but
IRC/Messaging Client: ???
PDF Reader: ???
Office Suite: LibreOffice , accept no substitutes
Calendar: ???
Video Player: VLC
Music Player: Rhythmbox
Photo Viewer: ???
Screen recording: Open Broadcaster Software
Satoshi Nakamoto's ID does not matter to Bitcoin
It *is* however of interest to persons wanting to either hire the elusive genius, or pick his brains on other complex algorithmical topics over an extended interview.
Most likely he hasn't even noticed, what with his head being likely stuck in a recursive integral he's been head-refining since last week.
I wonder if there are any, against all wisdom, control posts for nuclear facilities that are running Windows 7 or 8, that really, cannot, must not, be interrupted during sensitive operations.
That will be the BEST time to update.
Any publicity is good publicity, right?
This strikes me not so much about studying "free will" than our inability to operate on extremely small timescales.
Second of all, I would be very reticent to accept into general principle the idea that there is no free will.)
If free will exists but we assert it does not, we surrender it of our own volition: if there is hope, but we do not keep hope, then from our own decision, there is no longer hope.
No holy wars please. s/vim/$YOUREDITOR/g
If you're using a LAMP stack mainly (which it seems you are), the option of SSH and using a command line text editor could be of interest.
That being said, if you can create a dev environment that matches your production, why not git around? Where has this workflow failed you previously? Surely also you are developing on multiple servers for different projects, and there are things you do common to all servers?
For my sites I use generally two git repos - one for my toolchain (custom connection, management and setup scripts), one for base content. Given that I use Wordpress for a lot, I can duplicate some of the base work. I use digitalOcean, always a ubuntu 14.04 server, and always set up with the same scripts. I do have a test VM directly on my machine to test things that might seriously break stuff, or for dev when I'm on the go without network, but otherwise, a lot of what I do is "in the cloud" - just over SSH.
As to how this would map to your requirements:
1) No syncing hassles across machines If you're a team of one, SSH+cli editor should work - it's also lower processing power on your device. Better battery longevity. You can also quickly move back and forth between server logs and code from here too 2) No installation of toolchains to get working or back to work — a browser and a connection is all that would be required Unless I'm mistaken, you'll always have toolchains to install and update on every new site/server. So long as you maintain an easy way to deploy them fresh, and the new instances you spin up are always predictably similar, I see no problem with maintaining a toolchain deployment recipe in one place, and easily management of instances along the way in teh way you want (ansible, chef, puppet, custom scripts...). 3) Easy teamwork If the solution you want is for live coolaborative editing, maybe indeed a web-interface which facilitates this may be interesting, though you'll want to check that this mode of "team" working suites your team best, or if revision control-based solution works better for their workflows. Maybe a question for the web-based solution is, does it integrate well with individuals who like to work offline and sync as needed? I'll assume you've already had this talk with them. 4) Easy deployment I'd say this is down to DRY - Don't Repeat Yourself, or, have you automated everything you could have?At the end of the day, so long as you have revision control in whatever solution you choose, you have a decent chance of developing on production. Now about the databases...
I stand corrected.
1/ The Mythical Man Month was "referenced" (and mangled) about in an unrelated article by Eddy Baldry. It is he who mis-states the premise of the MMM
2/ Mythical Man Month's statement is "Adding more manpower to an already late project delays it further." This is different from the premise stated by Baldry.
3/ Anders Wallgren mentions nothing of the Mythical Man Month
4/ Wallgren actually does say that microservices, underpinning some of the arguments for DevOps, is not suitaed for all projects.
5/ The summary is a lie.
Have you considered using something other than BitLocker? https://alternativeto.net/software/windows-bitlocker/?license=opensource&platform=windows
And I'm gonna say it - why not use disk-encrypted Linux and put Windows in a VM for those one or two programs that are Windows-only? This way you have full control of your system, the whole disk is encrypted, and you can stick to Windows 7...
They carve a niche, realize it's a niche, abandon it.
Then open source solutuions come in to fill the gap and i make myself use them. May the trend continue.
So two thoughts come to me after reading the summary and the comments
1/ This clearly demonstrates that Linux is the right technology to use when supporting business syetms with legacy hardware (I'll second the opinions that enterprise keeps hardware around the longest - I supported users on obsolete AS/400s which, whilst not as old as what some people here talk about, still mean we're frequently learning old technology in Support); and the point that the leadership (Linus right now, hopefully the same with whomever comes to replace him eventually!) can be more ameanable to keeping up support for old hardware is great. I dream of desktop uptake, but enterprise and research are where it's at.
2/ However I also wonder - isn't this an offshoot problem of the fact that Linux is a monolothic kernel? Can this kind of interface-specific support not be modularized? Say, an API/ABI (in-kernel)standard that allows the kernel to plough on with currently evolving requirements, whilst maintaining a stable interface for previously integrated kernel features that have been split off into modules...?
(and no, I'm not at all familiar with the ins and outs of kernel development and architecture - I just read newsposts and Wikipedia ...)
Except that this has nothing to do with "attacks". The word "damage" is also applied to the "trust" and "credibility" of governmental institutions.
This kind of legislation would apply even if nobody died in the carrying out of the activity.
So the major players want to bring some order to the bazaar. So be it - they can try. There are small projects that will probably decide to cooperate, and will because they are a one- or two- person effort - but the projects that truly behave like a bazaar will remain as coordinated or uncoordinated as they still are.
I don't see this effort being capable of shoving an agenda down anybody's throats - if you don't care for the agenda, don't. Submit your code to the project as and when you see fit, and work on the bits you want to. If tomorrow they want to address what they see as glaring issues in GNU's netcat, they'll be able to throw resources at it collectively - but I doubt they'll be able to tap GNU's shoulder and say "hey, give us some of 'your' devs to fix this."
In the end, if the effort results in a pooled selection of developers, incentivized directly and collectively (read: employed) by the companies, to work on aspects of open source projects they have communal stake in, to common goals and specification, that is probably going to be a good thing.
If they fork any of the technologies that is fine too - that's exactly what GNU GPLv3 was meant to allow them to do. They just can't expect to fork the maintainers and community too.
If however there is a scenario in which volunteers can be coerced into their way or the highway, that scenario must be understood and countermeasures prepared by those who would stand to lose from it. Don't take it too seriously, but don't take it in any way lightly either.
The "highly restricted" spec is meant to catch suspicious combos like in the mybank example - but does not catch full-ascii (which is an even more restrictive level) trickery like tvvitter.com (notice the two "v" chars). that combo in particular is now known, but goes to demonstrate that trickery does not need charsets larger than 7-bit... some people simply get caught by hsbc.net...
From a user's perspective, three sources: the Linux Action Show podcast highlghts fun/useful items once a week.
Then there's tuxmachines.org which talks about.... well pretty much anything, you'll have to sift through the deluge...
Then just following what's generally popular, and using alternativeto.net to find open source counterparts...
In the original article an ArretSurImages.fr, the blogger details in her interview that she decided not to hire a lawyer, instead simply complied immediately and did not defend her position. She was not required by the court to remove her post, but she did so of her own accord.
A commenting lawyer interviewed for the article indicated that the case shows more the necessity of getting legal advice, rather than any evolution of rights on the Internet.
Yes it's sad that she was attacked for her criticisms, but it's sadder that she did not take responsibility, or stand her ground.
This is sounding like a LOIC - but that issues DMCA requests instead of network requests :-p
Hm. I would say "there goes my preference for not associating my phone with an online account" but that would actually be incorrect. Though I would indeed prefer not to have to have an account to install apps.
I guess I still treat my phone like a computer in many respects and I'm trying my darndest to keep it away from any form of remote kill at all for the sake of a "no remote please" blanket stance...
Still, I'm pretty sure I prefer to be slightly on the neurotic side.
Whilst all this may be valid and true, how are we going to prevent the "wrong people" from using this kill switch? Will it be hardware based, in which case, how will we be sure it won't be triggered/used remotely if we install a different OS on the device? Or if some script kiddie found a way of activating it by exploiting an insecure app?
(new hollywood armaggedon scenario: terrorists threaten to detonante a phone bomb that would activate kill switches around the world, bringing down entire civilizations)
Yes, a technological solution might exist for the problem; question is, is this one the right one? Are we going to stop looking for alternatives?
No, they meant Ctrl-X , Y
The main thing that is wrong with the Internet is that it's still an academic plaything.
It was invented for use in a lab, and extended for use by trustable peers across the country. Then someone opened the floodgates.
What we need is a base infrastructure that is paranoid by design, not trusting by nature.
Oh and one that is capable of handling bazillions of entities on it.
Reading the original article on Les Echos.fr, it seems to me this is not law but an agreement between a coalition of enterprise owners and the unions - they've signed an agreement to implement this.
A third union that didn't sign, the CGT, is actually deploring the fact that it still has a loophole allowing it to be ignored, and a previous agreement between the two camps to try and improve working conditions was struck down by a court of law:
French journalistic style is not as easy to decipher as English-language journalism -- the French style is very fond of appearing as literary as possible. I'll post extra translations at some point if anybody wants.
Anybody who has tried to put a bog-standard user on Free Software Only laptops (Yeelong or X60 exclusively) with only Free Software and no proprietary.... knows that the user runs screaming back to the motherly proprietary vendors with reinforced assurance that the FSF are nuts. And we all lose.
I'd phrase it like this:
On the whole however I think the idea is spot on. Could do with some <h1> and <h2> lines to help the TL;DR crowd.
TDF should be pushing their scriptable LibreOffice, and point out the benefits of not having to purchase it either now or in the future, the freedom of open formats, and also the benefits from a "smart kids" point of view to giving them an open-sourced office suite they can tinker with.
If companies see value in using Microsoft's full suite and stack, more power to them both. In the mean time, from an educational, budget and general open formats point of view, LibreOffice is the way to go.
Heck, if it's about kids' programming skills, and if the kids think they can improve the scriptability of the application itself, they could even submit their own patches and features to LO. Not so with MSO.