Nobody cares that your router runs in 128 megs of RAM, when it does not provide the ease of use or rapid development provided by high level application frameworks. And yes I've built plenty of Linux boxes (with as little as 4 MEG - your 32 meg router was 4x the size of my first X11 box) myself. Thing is - they aren't desktops.
Ran Desktops with 4 MB RAM myself. Not saying today's desktop's shouldn't have more memory, but that additional memory and CPU should let you actually do more with the computer, not the same amount or less.
As far as a desktop environment goes - It isn't a "waste" of resources, it is a trade-off for programmer efficiency..
Incorrect. It's not a matter of "programmer efficiency", it's a matter of "software efficiency". The two are not necessarily the same.
"Programmer Efficiency" is how well the programmer is skilled in the field.
"Software Efficiency" is how efficient the software is with resources on the computer it is running on.
A skilled programmer (e.g, one with a high programmer efficiency) can create software that has a high "software efficiency".
A unskilled programmer (e.g, one with a low programmer efficiency, typically in high school or right out of college) will not typically write software that has a very high "software efficiency", rather it will be very low on the "software efficiency" side. They're just not skilled enough to choose the right algorithms or implement the algorithsm in a very efficient manner.
The problem is that too many companies want to only use programmers with a low "programmer efficiency" because they're "cheaper" per hour than one with a higher programmer efficiency. Unfortunately, two (or more) low skilled developers do not necessarily equate one high skilled developer (Mythical Man Month).
And yes, you can choose to have the software be a little less efficient, but knowing how to that smartly is a key thing. For instance, you want your producitivity suite to be highly efficient in the user interface, but it doesn't need to be as efficient on its background processing. Knowing how to make that trade off requires more experience.
As any computer scientist will tell you - computing power scales, human processing power does not. In other words, processor time/RAM is cheap. Programmer time is not.
Computer Science views the computer resources as unlimited, inline with the Turing Machine (unlimited storage, unlimited processing, etc.)
Software Engineering views the computer resources as limited, inline with computers you actually find in use around the world.
Yes, human processing does not scale well, and programmer time is not cheap. But that doesn't mean you can waste the user's time and resources either - they're not unlimited. And it can very well make the difference between a user purchasing your product or a competitors, or using your FOSS software versus buying something proprietary.
CPU, Memory, and Hard Disks are relatively cheap; but they're not necessarily cheap for the end-user.
This is why we do not code everything in assembly language - it is only used if absolutely necessary.
No one said you should use Assembly; only that you need to be conscience of the computer resources that are used by your software. Whether you are using Assembly, C, C++, Python, Java, C#, SmallTalk, Ada, Pascal, Cobol, Ruby, D, or whatever the next big language is - you have to be conscience of what the computer is doing and when in order to make your programmers work efficiently in ways that have the least system/user impact.
which is why it takes gigacycles (and 10x the ram) to do the same things we used to do in a few megacycles.. It's one thing to not obsess over every extra loop or cache miss, but that doesn't excuse the slovenly, bloated mess that is the average software application today.
Exactly. We shouldn't treat the computer as having "unlimited CPU and RAM", which is what Computer Science teaches (and Java/C#/VM-language developers generally expect) because it isn't. You don't need to fret over every little byte usage in memory or CPU, but you also need to be conscience of it so you don't waste it either.
There is no reason why a program from today should run slower than its equivalent 10/15/20/30 years ago. Yet that is often the case.
Nor have I ever needed to know the kernel version when installing via package manager.In fact I cannot recall ever needing to know the kernel version installing outside of the package manager either.
VMware can be a PITA - you have to know the kernel version as you might have to fix their driver modules after so long due to breaking when there have been changes to the kernel. I use VMware 8.x at work on a relatively new kernel (3.8); had to fix source to make it work.
Still, running it on numerous systems - VMware is certainly the exception, and that's probably due to it being proprietary software that has to interface with the Linux Kernel to do its job.
Specifically, there is basically nobody who properly markets Linux, so a lot of people have never heard of it and even those that have largely think it's a command-line only hardcore-geek thing
So of the people who have heard of Linux properly categorized it as a hardcore-geek thing? OK, perhaps not hardcore-geek, maybe even casual-geek, but certainly not a non-geek thing.
In my office, I'm the 'IT-guru' simply because I know how to fix the margin settings in MS Word or how to get an excel table to properly import into Powerpoint. THAT is technical wizardry to most people, so think about how non-geek friendly Linux really is.
Unless the marketing is cleverly disguised training-infotainment that teaches people the differences between what they do now, and how things work in Linux, most people will balk at something as simple as having the window min/max/close buttons on the left hand side of the window.
Linux is not really that bad any more, especially with the maturity of KDE, and they wouldn't really notice the differences aside from not being able to go to Staple/OfficeMax/OfficeDepot/BestBuy and pick something up and have it "just work".
The only way I've found to ever successfully switch someone from one OS to another is to completely eliminate any possiblity for that person to use their original OS. Including myself.
That has generally been the consensus with any kind of conversion, supported by various studies. Companies that successfully transition off a Microsoft technology (Windows, Office) generally have to do just that - remove all possibility of going back. People adjust, after some time complaining; then they start rejoicing - but they'll continue to complain about missing their forced Coffee-breaks.
Switching from iOS to Android? Had to switch to Verizon before they had the iPhone so my old iPhones were either sold or used as home remote controls.
Switching from WindowsXP to 7? Upgraded to 16GB of RAM, (some other incompatabilities as well)
Switching to Windows8? Installed on the 'kitchenPC' and..... oh who am I kidding. I need to get XP on that machine ASAP. Even with a multi-touch pad that damned thing drives me nuts.
Switching to macOS? Install Windows 8 on your kitchenPC.
That depends on whether it is something work keeping. If it isn't, then it wasn't worth it at the old price either.
You're right in this case, where the customer can consent to removing the cap. I'm more concerned about what happens when regulators forget the consent portion, and force both the company and the customer into a situation neither wanted.
This is more applicable when caps are too low, but in any case, it could be those customers that would happily pay more than the cap that keep the service profitable via economies of scale.
I can see usefulness for caps on Wireless Data Plans for cell phones.
For any other device, the cap ought to be required by law to be the amount of data potentially transferred at the rate sold for the entirety of the month - e.g. X speed * (3600 * 24 * 365.25 / 12) or (simpler) X speed * (3600 * 24 * 31), though months with fewer than 30 days will have a little extra. Anything less, is really not delivering the service the customer is paying for. And if it's not profitable, then they need to be selling slower connections that are instead of letting the marketing department determine sales - it needs to be a mix of marketing, engineering, and management mitigating the two.
I think I would like the changes overall, but any regulation has trickle-down effects. For instance, capping the price of certain services may be realized by capping the ability to use the service, or removing the service altogether if it is no longer profitable.
That depends on whether it is something work keeping. If it isn't, then it wasn't worth it at the old price either. Honestly, data plans are being charged at way too high an amount, and can be very unsuspecting so yes - something needs to be done in terms of regulation, USA included.
And of course, FTA:
There's a good chance, however, that Canadians could see the price they pay for their cellphones up front rise as a consequence of their newly won long-term freedom.
That wouldn't be a bad thing really. People have too low a value on their phones, so they don't treat them well, then wonder why they're breaking - which in turn drives up the cost for the carriers. Make people realize the real value of the device.
Honestly, I wouldn't mind if carriers were prohibited from subsidizing devices entirely, but that won't happen. This is certainly one area where Europe has a little better model than the USA/Canada, at least in this one respect.
If you have good unit tests it wont be anywhere near 40%. Automated testing is a lot faster than manual regression testing. Assuming of course you are talking about fixing something like Google.com or Java where the cost of failure it relatively low.
If you are fixing pacemakers, you really need to ask yourself why you put a webserver or browser in it to be compromised in the first place.
Even automated regression and unit testing takes time. Even on mid-size projects, it could easily be a few days just to run the automated testing suite in all the supported environments to guarantee you didn't break something. For a large project, it could be weeks or more.
While I generally agree, some projects (like Qt for instance) take a week or more to test something before making a release to production to verify that what was intended to be changed actually was changed, and that it didn't break anything else. This is especially true of platform API projects like Qt, Gtk, etc. where many people rely on the stability of the APIs in those projects, and people using the project then need to have their own testing time on top of that.
However, it also goes to underscore the importance of making notices about vulnerabilities and how to at least minimize their impact within a quick time frame so that downstream products as well as administrators of existing products can have appropriate notice to (i) minimize their own exposure, and (ii) start planning for integration of new releases of their upstream dependencies so that they can (iii) make their own notices for their downstream customers.
Ultimately it may not be fixed in every location for 6 months or more; but the sooner people can start fixing or minimizing exposure the better for everyone.
The big kicker is "under active exploitation". If no exploits are known in the wild, it's still necessary to light a fire under the vendor's ass(you can't assume that the flaw isn't just sitting in somebody's high-value-zero-day arsenal, or that it won't be discovered and exploited in the future); but there is a real argument in favor of trying to work with the vendor to get a proper fix in place before releasing the details, and more or less assuring that every dumb script kiddie can implement the attack if they want.
And yet Microsoft's policy is that unless it is "under active exploitation" they won't necessarily fix it. They get lots of notices about potential exploits, but don't fix them, even likely high targets, until someone exploits them - which, by then, is really too late.
You're right, it's bad software. Use Linux instead. Expecting real uptime on windows is laughable. I can leave win 7 running with nothing open and come after holiday to find it in a worse state.
Not to mention that the Windows "up-time" counter only allows it to be up for just over 49 days (but not 50 days) before it rolls over. So even Microsoft expects Windows to be rebooted quite regularly.
I'm working on a project and I don't want to lose my place
Then bug the developers of the applications that you use in your project to include session save and restore.
Often they just need to save/open a Word document or something similar...the main issue is they don't want to take the 20-30 minute coffee break while the system boots back up or logs in due to all the crap they have running that they don't really need, or that corporate forces on them.
I hear you. It's good to know I'm not the only one. Although I extend that to being a borg of only one entity. Your distinctiveness is not necessary, you will NOT be assimilated! Imagine not having one body, but as many miriad forms as your imagination, engineering and environmental requirements allow. I would like to float in the magnetoshere of the sun, crawl into the Earths mantle, surf on a wave of liquid methane. There is such a huge universe out there and I want to experience it all.
You need to read Peter F. Hamilton's Commonwealth Saga books - Void Trilogy, etc.
Actually what you describe works flawlessly for me. I know that getting styles right is complex, but my point is that it is eventually worth it, as you can restrict the document to those styles once ready (avoiding other people messing with formatting) and reuse the template time and again. Let me share and example: http://www.filedropper.com/generictemplate-nocover
Word could actually improve a lot by separating style definition from content, and making the first one vastly easier and more accessible.
Hope it helps:-)
What I describe works out of the box flawlessly with OpenOffice and LibreOffice, but requires modifications to Word Styles to make it work right? Sorry, I that doesn't cut it.
That said, I am now running into an issue with O/L Office Impress regarding sub-slideshows. In PowerPoint you just point the URL at your sub-slideshow and it just works - click on the link, and it returns when the sub-slideshow is done. Impress seems to get as far as doing 1 slide that way, but won't do multiple slides. A PITA for anyone doing major slideshows and wants to keep a common outline instead of duplicating outline slides.
You're sarcastic response not withstanding, the point you make is correct. However, in reality a review of something on this scale will necessarily be accompanied by a review of the software. MS has a bad history when it comes to supporting open standards - they like to tweak and extend them - html, css, c++ just for starters. This will make the adoption of ODF by the govt less appealing because they will be relying on MS to behave. So, what are they left with? OpenOffice, AbiWord LibreOffice. If these get rejected as non-business suitable then ODF may follow quickly behind them.
Yes, and MS Office has had support for ODF for a while - however, in a very incompatible manner. All the cells are defined to the values, and the formulas are put in a MS-Excel only section. So other program can provide the calculations without the user going back and re-entering all the formulas.
I want to make it clear that I agree with the idea of moving to ODF, but I have seen how these things get killed off in their infancy time and time again because of entrenched systems.
Yes. And it's cool to see a First-world country adopting it. (Though parts of Australia are certainly Third-World....)
Allow me to introduce you to Styles. Create or download a template you like. Block styles to avoid any weird format to get into your documents, Then applying styles to parts of your text is a matter of selct and click. I can format an extensive document with no flaws in a matter of minutes.
They also create a lot of problems.
Honestly, even when I was using WIndows and Office I would go to OpenOffice to write my document and get all the styles, outlines, etc. correct b/c Word just couldn't do it without screwing things up; then I'd save it as a Word document, open it in Word and check the cross-references (usually having to redo them as Word doesn't like them out of OpenOffice), and deliver to colleagues and clients.
Sad thing is - I wasn't really trying to do something very hard - just get a 1, 1.1, 1.1.1 style outline most of them time - with descriptions (paragraphs) under each one. Doing it straight out as if I was just typing out a written document generally works, but if you're going back and forth on a work in progress document, then it's a never ending cycle of fixing the outline levels. (Yeah, add an outline entry, may be more than one, fill in the outline, add on to the end, add stuff in the middle, and try to keep it consistent by just using tab and shift+tab to go between levels; Word just croaks and messes it all up.)
The SD card bootloop problem is well known and spread across a large number of devices. Take a look.
It is not any app causing the problem, it's Android itself. It's suspected that it happens either after a certain number of apps/files are moved or a certain amount of space is used by apps on the SD card.
Well, my N1 doesn't have an issue - either with stock Android or Cyogenmod7 - where I more heavily moved apps to the SD card than with Stock since stock wouldn't allow some apps to go to SD Card, while a lot more can with C7.
It's mostly likely due to something that the OEMs/Carriers did by allowing some critical piece of software to be moved to the SD card.
And the only "boot loop" issue I had was a memory allocation issue by the Activity Manager completely unrelated to whether or not the SD card was present.
Logic fail.
Justin Bieber has millions of fans too. I guess that makes him a fantastic musician.
Additionally, by the same logic, that makes Windows a superior desktop OS to any of the Linux distros.
Yes it is, there are two types of project in the world - those where the time for production is a fairly well known and those where it's not. When you've built a few houses you know roughly how many bricks your bricklayers can lay in a day, you know how long it takes to install the plumbing, these are tasks that you do many times and within a certain degree of tolerance are highly predictable in terms of time required.
You can't do that with software, because everything you write is new (and if it isn't, you're doing it wrong, why aren't you taking advantage of reusable components?) so you simply cannot predict ahead of time how long something will take with any reasonable degree of guarantee. The same is true for many research projects, the same is true for a lot of engineering projects. Projects in industries like these aren't like production lines where you have masses of historical data on identical or near identical tasks to go on - you know your factory can churn out 10,000 chocolate bars in a day on average, but you don't know that your team of software developers can definitely solve problem x in a day.
As much as I disagree with how managers estimate time for projects, you can very well do that with software. However, you need software developers that are professionals, and not about being artistic. People that will stick to team guidelines, coding styles, design guidelines, etc, and people with experience. The more experience you have the better you'll get at estimating your own time.
And yes, I've seen that even with myself. In the early phase of a brand new project it can be harder to estimate time correctly, but as some of the technology in the project matured, other phases became a lot easier. Following design guidelines have reduced bugs to very low levels - near zero across over 400 KSLOC, most things users complain about are not bugs but product maturity (e.g. I don't have infrastructure in place to support what they want yet) - i.e. it's not bugs, but new features to add. (Bugs being defined as defects in existing code, not missing features.)
Software developers that insist that it cannot be done are simply (i) inexperienced, or (ii) do not know what they are doing and need to not be doing software.
"When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting."
This shows a complete lack of experience on your behalf on dealing with clients. If you act like this you'll a) often be wasting more of your time and their time renegotiating contracts than you will just doing the changes because the changes rarely come in one big bulk lump, but normally come in at a trickle, and b) Your customers wont be your customers because forcing them to waste time with a contract renegotiation over say, roughly a days work is the quickest way to piss them off and show how inflexible you are. They'll go elsewhere.
No. It shows you know you have contracts work. You are bound to the contract you've signed. If you don't follow the contract and they have a problem, then you are on the hook for what is written in the contract. If they ask you for something that is not in the contract, then you can do it - but it won't be something they'd be able to hold you to.
In the end, your customer may complain at first; but when they get what they want they'll be happy. Make the contract renegotiation easy for them, and show them that the renegotiation is as much about them getting what they want and keeping them happy as it is ensuring that you are properly paid.
Yes, there is a line where you can say - well, the contract doesn't say that, but we'll do it any way. And that's a line you have to figure out how to walk. But you also cannot simply roll over and say "well, if t
But we're not talking about a house which is normally something you can quantify as taking x amount of time to a pretty reasonable degree if you've done it before, we're talking about software.
It's no different for the software industry.
I think just about every software contractor has clued into the fact that software requirements change much more rapidly and if I was on the hiring side of the equation I'd be loathe to take on a contractor that didn't want to be paid by the hour, day, or week, and instead wanted to be paid for the full job, as it would say to me that they didn't have the necessary experience to understand the way software is built and what can go wrong because both I and they would be exposed to far too much risk to be healthy.
When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting. All too often with software the developers do not renegotiate thinking it'll be easy to add, thus allowing feature creep that they are responsible for. A good contractor will be good at controlling the feature creep - this is extremely helpful by forcing contract renegotiations whenever a new feature is requested that was not in the original specification. Add in a contract renegotiation fee for each change, and they'll quickly get the picture that they can't keep changing things.
I had one colleage nearly a decade ago that worked on a project for another manager. She micromanaged things, and would tell him what to change. Our manager didn't really care, or pay much attention to it. She didn't really specify requirements, and in the end it would have been something like having an invisible elephant that you can see and has pink dots without any pink involved. He left the company. She later brought another contractor in and he told her that what she was asking was impossible and the code would have to be restarted from scratch (it was a mess due to her micromanagement). The project died.
Interesting that you're not prepared to guarantee your work. It would make me wary of contracting you as it places the onus on me to ensure that I've throughly tested your code rather than on you. Is this common practice?
This entire discussion has either misused the term "contracting", or deliberately glossed over it (by which I don't mean to accuse you specifically, the whole thread has that problem).
When I work under salary, I get paid for projects (along with a certain amount of "keeping the lights on" shit-work, of course). I work unpaid OT if necessary, and cut out early when ahead of schedule. I generally expect (and get) a very flexible schedule so long as I get my tasks done.
When I work as a contractor (and yes, I do both), I get paid for my time. I'll give a good estimate of how long it will take me, but if we run over, you keep paying. Simple as that. Yes, that could potentially lead to abuses by unscrupulous programmers - And they wouldn't get any repeat work for pulling crap like that. Just part of the game: Find a few that work well with/for you, and make them happy enough to stick around.
That depends on the contract, of which there are several ways:
Hourly
By Project
On retainer (typically for a certain amount of time)
If he contracted them "by project", then the contractor is on the hook for fulfilling all the contract requirements regardless of time; the contractor better hope they estimated it correctly as they're on the hook until the customer signs-off on it. This is essentially a "salaried" contract; but it is not working as a salaried employee.
If he contracted them "hourly", then it is more his issue than the contractors.
However, from the description it sounds like he does "by project" contracting; but there's not really enough information to say.
You don't get to decide when a word is pejorative to a group that's historically been targeted with it.
FYI - it was a word adopted by the homosexual community (circa 1960's and 1970's) to try to replace the term "queer", and to convey a certain message in the process. Over time, though, it has come to be a synonym for "queer" instead.
Just goes to show that one can call something anything they like, but the name will eventually mean the same thing as what was originally given it.
Yeah! It's like saying that 97% of priest believe in god anyway.
This just reveals your wooly thinking. TFA doesn't say "97% of scientists believe in AGW". It's 97% of scientific papers.
True.
i.e. 97% of the ways of examining the question scientifically resulted in a conclusion that AGW is real. Scientific method, not belief.
False.
97% of the papers may have used the same method, or various revisions thereof. There is nothing saying they all used different methodologies.
All TFA says is that 97% of published papers and 97% of the surveyed researchers that work on them said AGW is man-made. It says nothing about the quality or validity of those papers, the credentials of the researchers, etc. For all we know, 97% of those researchers were ungrad-students doing research for a professor that required them to assume AGW was man-made.
You do realize medicare/medicaide is more expensive than private insurance, don't you? Sure, you may not pay for it up front when visiting the doctor or paying for your drugs, but you do pay for it in taxes, along with everyone else.
Slashdot Mirror
Nobody cares that your router runs in 128 megs of RAM, when it does not provide the ease of use or rapid development provided by high level application frameworks. And yes I've built plenty of Linux boxes (with as little as 4 MEG - your 32 meg router was 4x the size of my first X11 box) myself. Thing is - they aren't desktops.
Ran Desktops with 4 MB RAM myself. Not saying today's desktop's shouldn't have more memory, but that additional memory and CPU should let you actually do more with the computer, not the same amount or less.
As far as a desktop environment goes - It isn't a "waste" of resources, it is a trade-off for programmer efficiency..
Incorrect. It's not a matter of "programmer efficiency", it's a matter of "software efficiency". The two are not necessarily the same.
"Programmer Efficiency" is how well the programmer is skilled in the field.
"Software Efficiency" is how efficient the software is with resources on the computer it is running on.
A skilled programmer (e.g, one with a high programmer efficiency) can create software that has a high "software efficiency". A unskilled programmer (e.g, one with a low programmer efficiency, typically in high school or right out of college) will not typically write software that has a very high "software efficiency", rather it will be very low on the "software efficiency" side. They're just not skilled enough to choose the right algorithms or implement the algorithsm in a very efficient manner.
The problem is that too many companies want to only use programmers with a low "programmer efficiency" because they're "cheaper" per hour than one with a higher programmer efficiency. Unfortunately, two (or more) low skilled developers do not necessarily equate one high skilled developer (Mythical Man Month).
And yes, you can choose to have the software be a little less efficient, but knowing how to that smartly is a key thing. For instance, you want your producitivity suite to be highly efficient in the user interface, but it doesn't need to be as efficient on its background processing. Knowing how to make that trade off requires more experience.
As any computer scientist will tell you - computing power scales, human processing power does not. In other words, processor time/RAM is cheap. Programmer time is not.
Computer Science views the computer resources as unlimited, inline with the Turing Machine (unlimited storage, unlimited processing, etc.) Software Engineering views the computer resources as limited, inline with computers you actually find in use around the world.
Yes, human processing does not scale well, and programmer time is not cheap. But that doesn't mean you can waste the user's time and resources either - they're not unlimited. And it can very well make the difference between a user purchasing your product or a competitors, or using your FOSS software versus buying something proprietary.
CPU, Memory, and Hard Disks are relatively cheap; but they're not necessarily cheap for the end-user.
This is why we do not code everything in assembly language - it is only used if absolutely necessary.
No one said you should use Assembly; only that you need to be conscience of the computer resources that are used by your software. Whether you are using Assembly, C, C++, Python, Java, C#, SmallTalk, Ada, Pascal, Cobol, Ruby, D, or whatever the next big language is - you have to be conscience of what the computer is doing and when in order to make your programmers work efficiently in ways that have the least system/user impact.
which is why it takes gigacycles (and 10x the ram) to do the same things we used to do in a few megacycles.. It's one thing to not obsess over every extra loop or cache miss, but that doesn't excuse the slovenly, bloated mess that is the average software application today.
Exactly. We shouldn't treat the computer as having "unlimited CPU and RAM", which is what Computer Science teaches (and Java/C#/VM-language developers generally expect) because it isn't. You don't need to fret over every little byte usage in memory or CPU, but you also need to be conscience of it so you don't waste it either.
There is no reason why a program from today should run slower than its equivalent 10/15/20/30 years ago. Yet that is often the case.
Nor have I ever needed to know the kernel version when installing via package manager.In fact I cannot recall ever needing to know the kernel version installing outside of the package manager either.
VMware can be a PITA - you have to know the kernel version as you might have to fix their driver modules after so long due to breaking when there have been changes to the kernel. I use VMware 8.x at work on a relatively new kernel (3.8); had to fix source to make it work.
Still, running it on numerous systems - VMware is certainly the exception, and that's probably due to it being proprietary software that has to interface with the Linux Kernel to do its job.
Specifically, there is basically nobody who properly markets Linux, so a lot of people have never heard of it and even those that have largely think it's a command-line only hardcore-geek thing
So of the people who have heard of Linux properly categorized it as a hardcore-geek thing? OK, perhaps not hardcore-geek, maybe even casual-geek, but certainly not a non-geek thing.
In my office, I'm the 'IT-guru' simply because I know how to fix the margin settings in MS Word or how to get an excel table to properly import into Powerpoint. THAT is technical wizardry to most people, so think about how non-geek friendly Linux really is.
Unless the marketing is cleverly disguised training-infotainment that teaches people the differences between what they do now, and how things work in Linux, most people will balk at something as simple as having the window min/max/close buttons on the left hand side of the window.
Linux is not really that bad any more, especially with the maturity of KDE, and they wouldn't really notice the differences aside from not being able to go to Staple/OfficeMax/OfficeDepot/BestBuy and pick something up and have it "just work".
The only way I've found to ever successfully switch someone from one OS to another is to completely eliminate any possiblity for that person to use their original OS. Including myself.
That has generally been the consensus with any kind of conversion, supported by various studies. Companies that successfully transition off a Microsoft technology (Windows, Office) generally have to do just that - remove all possibility of going back. People adjust, after some time complaining; then they start rejoicing - but they'll continue to complain about missing their forced Coffee-breaks.
Switching from iOS to Android? Had to switch to Verizon before they had the iPhone so my old iPhones were either sold or used as home remote controls.
Switching from WindowsXP to 7? Upgraded to 16GB of RAM, (some other incompatabilities as well)
Switching to Windows8? Installed on the 'kitchenPC' and..... oh who am I kidding. I need to get XP on that machine ASAP. Even with a multi-touch pad that damned thing drives me nuts.
Switching to macOS? Install Windows 8 on your kitchenPC.
Now that's just funny...especially that last one.
That depends on whether it is something work keeping. If it isn't, then it wasn't worth it at the old price either.
You're right in this case, where the customer can consent to removing the cap. I'm more concerned about what happens when regulators forget the consent portion, and force both the company and the customer into a situation neither wanted.
This is more applicable when caps are too low, but in any case, it could be those customers that would happily pay more than the cap that keep the service profitable via economies of scale.
I can see usefulness for caps on Wireless Data Plans for cell phones.
For any other device, the cap ought to be required by law to be the amount of data potentially transferred at the rate sold for the entirety of the month - e.g. X speed * (3600 * 24 * 365.25 / 12) or (simpler) X speed * (3600 * 24 * 31), though months with fewer than 30 days will have a little extra. Anything less, is really not delivering the service the customer is paying for. And if it's not profitable, then they need to be selling slower connections that are instead of letting the marketing department determine sales - it needs to be a mix of marketing, engineering, and management mitigating the two.
I think I would like the changes overall, but any regulation has trickle-down effects. For instance, capping the price of certain services may be realized by capping the ability to use the service, or removing the service altogether if it is no longer profitable.
That depends on whether it is something work keeping. If it isn't, then it wasn't worth it at the old price either. Honestly, data plans are being charged at way too high an amount, and can be very unsuspecting so yes - something needs to be done in terms of regulation, USA included.
And of course, FTA:
There's a good chance, however, that Canadians could see the price they pay for their cellphones up front rise as a consequence of their newly won long-term freedom.
That wouldn't be a bad thing really. People have too low a value on their phones, so they don't treat them well, then wonder why they're breaking - which in turn drives up the cost for the carriers. Make people realize the real value of the device.
Honestly, I wouldn't mind if carriers were prohibited from subsidizing devices entirely, but that won't happen. This is certainly one area where Europe has a little better model than the USA/Canada, at least in this one respect.
I wouldn't call Windows not functioning properly on PC's a compatibility issue.
No, it's a feature.
If you have good unit tests it wont be anywhere near 40%. Automated testing is a lot faster than manual regression testing. Assuming of course you are talking about fixing something like Google.com or Java where the cost of failure it relatively low. If you are fixing pacemakers, you really need to ask yourself why you put a webserver or browser in it to be compromised in the first place.
Even automated regression and unit testing takes time. Even on mid-size projects, it could easily be a few days just to run the automated testing suite in all the supported environments to guarantee you didn't break something. For a large project, it could be weeks or more.
While I generally agree, some projects (like Qt for instance) take a week or more to test something before making a release to production to verify that what was intended to be changed actually was changed, and that it didn't break anything else. This is especially true of platform API projects like Qt, Gtk, etc. where many people rely on the stability of the APIs in those projects, and people using the project then need to have their own testing time on top of that.
However, it also goes to underscore the importance of making notices about vulnerabilities and how to at least minimize their impact within a quick time frame so that downstream products as well as administrators of existing products can have appropriate notice to (i) minimize their own exposure, and (ii) start planning for integration of new releases of their upstream dependencies so that they can (iii) make their own notices for their downstream customers.
Ultimately it may not be fixed in every location for 6 months or more; but the sooner people can start fixing or minimizing exposure the better for everyone.
The big kicker is "under active exploitation". If no exploits are known in the wild, it's still necessary to light a fire under the vendor's ass(you can't assume that the flaw isn't just sitting in somebody's high-value-zero-day arsenal, or that it won't be discovered and exploited in the future); but there is a real argument in favor of trying to work with the vendor to get a proper fix in place before releasing the details, and more or less assuring that every dumb script kiddie can implement the attack if they want.
And yet Microsoft's policy is that unless it is "under active exploitation" they won't necessarily fix it. They get lots of notices about potential exploits, but don't fix them, even likely high targets, until someone exploits them - which, by then, is really too late.
You're right, it's bad software. Use Linux instead. Expecting real uptime on windows is laughable. I can leave win 7 running with nothing open and come after holiday to find it in a worse state.
Not to mention that the Windows "up-time" counter only allows it to be up for just over 49 days (but not 50 days) before it rolls over. So even Microsoft expects Windows to be rebooted quite regularly.
I'm working on a project and I don't want to lose my place
Then bug the developers of the applications that you use in your project to include session save and restore.
Often they just need to save/open a Word document or something similar...the main issue is they don't want to take the 20-30 minute coffee break while the system boots back up or logs in due to all the crap they have running that they don't really need, or that corporate forces on them.
I hear you. It's good to know I'm not the only one. Although I extend that to being a borg of only one entity. Your distinctiveness is not necessary, you will NOT be assimilated! Imagine not having one body, but as many miriad forms as your imagination, engineering and environmental requirements allow. I would like to float in the magnetoshere of the sun, crawl into the Earths mantle, surf on a wave of liquid methane. There is such a huge universe out there and I want to experience it all.
You need to read Peter F. Hamilton's Commonwealth Saga books - Void Trilogy, etc.
Actually what you describe works flawlessly for me. I know that getting styles right is complex, but my point is that it is eventually worth it, as you can restrict the document to those styles once ready (avoiding other people messing with formatting) and reuse the template time and again. Let me share and example: http://www.filedropper.com/generictemplate-nocover Word could actually improve a lot by separating style definition from content, and making the first one vastly easier and more accessible. Hope it helps :-)
What I describe works out of the box flawlessly with OpenOffice and LibreOffice, but requires modifications to Word Styles to make it work right? Sorry, I that doesn't cut it.
That said, I am now running into an issue with O/L Office Impress regarding sub-slideshows. In PowerPoint you just point the URL at your sub-slideshow and it just works - click on the link, and it returns when the sub-slideshow is done. Impress seems to get as far as doing 1 slide that way, but won't do multiple slides. A PITA for anyone doing major slideshows and wants to keep a common outline instead of duplicating outline slides.
You're sarcastic response not withstanding, the point you make is correct. However, in reality a review of something on this scale will necessarily be accompanied by a review of the software. MS has a bad history when it comes to supporting open standards - they like to tweak and extend them - html, css, c++ just for starters. This will make the adoption of ODF by the govt less appealing because they will be relying on MS to behave. So, what are they left with? OpenOffice, AbiWord LibreOffice. If these get rejected as non-business suitable then ODF may follow quickly behind them.
Yes, and MS Office has had support for ODF for a while - however, in a very incompatible manner. All the cells are defined to the values, and the formulas are put in a MS-Excel only section. So other program can provide the calculations without the user going back and re-entering all the formulas.
I want to make it clear that I agree with the idea of moving to ODF, but I have seen how these things get killed off in their infancy time and time again because of entrenched systems.
Yes. And it's cool to see a First-world country adopting it. (Though parts of Australia are certainly Third-World....)
Allow me to introduce you to Styles. Create or download a template you like. Block styles to avoid any weird format to get into your documents, Then applying styles to parts of your text is a matter of selct and click. I can format an extensive document with no flaws in a matter of minutes.
They also create a lot of problems.
Honestly, even when I was using WIndows and Office I would go to OpenOffice to write my document and get all the styles, outlines, etc. correct b/c Word just couldn't do it without screwing things up; then I'd save it as a Word document, open it in Word and check the cross-references (usually having to redo them as Word doesn't like them out of OpenOffice), and deliver to colleagues and clients.
Sad thing is - I wasn't really trying to do something very hard - just get a 1, 1.1, 1.1.1 style outline most of them time - with descriptions (paragraphs) under each one. Doing it straight out as if I was just typing out a written document generally works, but if you're going back and forth on a work in progress document, then it's a never ending cycle of fixing the outline levels. (Yeah, add an outline entry, may be more than one, fill in the outline, add on to the end, add stuff in the middle, and try to keep it consistent by just using tab and shift+tab to go between levels; Word just croaks and messes it all up.)
The SD card bootloop problem is well known and spread across a large number of devices. Take a look.
It is not any app causing the problem, it's Android itself. It's suspected that it happens either after a certain number of apps/files are moved or a certain amount of space is used by apps on the SD card.
Well, my N1 doesn't have an issue - either with stock Android or Cyogenmod7 - where I more heavily moved apps to the SD card than with Stock since stock wouldn't allow some apps to go to SD Card, while a lot more can with C7.
It's mostly likely due to something that the OEMs/Carriers did by allowing some critical piece of software to be moved to the SD card.
And the only "boot loop" issue I had was a memory allocation issue by the Activity Manager completely unrelated to whether or not the SD card was present.
Logic fail. Justin Bieber has millions of fans too. I guess that makes him a fantastic musician. Additionally, by the same logic, that makes Windows a superior desktop OS to any of the Linux distros.
lol, but Windows is prefered choice for Desktop.
Only b/c of legacy software.
"It's no different for the software industry."
Yes it is, there are two types of project in the world - those where the time for production is a fairly well known and those where it's not. When you've built a few houses you know roughly how many bricks your bricklayers can lay in a day, you know how long it takes to install the plumbing, these are tasks that you do many times and within a certain degree of tolerance are highly predictable in terms of time required.
You can't do that with software, because everything you write is new (and if it isn't, you're doing it wrong, why aren't you taking advantage of reusable components?) so you simply cannot predict ahead of time how long something will take with any reasonable degree of guarantee. The same is true for many research projects, the same is true for a lot of engineering projects. Projects in industries like these aren't like production lines where you have masses of historical data on identical or near identical tasks to go on - you know your factory can churn out 10,000 chocolate bars in a day on average, but you don't know that your team of software developers can definitely solve problem x in a day.
As much as I disagree with how managers estimate time for projects, you can very well do that with software. However, you need software developers that are professionals, and not about being artistic. People that will stick to team guidelines, coding styles, design guidelines, etc, and people with experience. The more experience you have the better you'll get at estimating your own time.
And yes, I've seen that even with myself. In the early phase of a brand new project it can be harder to estimate time correctly, but as some of the technology in the project matured, other phases became a lot easier. Following design guidelines have reduced bugs to very low levels - near zero across over 400 KSLOC, most things users complain about are not bugs but product maturity (e.g. I don't have infrastructure in place to support what they want yet) - i.e. it's not bugs, but new features to add. (Bugs being defined as defects in existing code, not missing features.)
Software developers that insist that it cannot be done are simply (i) inexperienced, or (ii) do not know what they are doing and need to not be doing software.
"When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting."
This shows a complete lack of experience on your behalf on dealing with clients. If you act like this you'll a) often be wasting more of your time and their time renegotiating contracts than you will just doing the changes because the changes rarely come in one big bulk lump, but normally come in at a trickle, and b) Your customers wont be your customers because forcing them to waste time with a contract renegotiation over say, roughly a days work is the quickest way to piss them off and show how inflexible you are. They'll go elsewhere.
No. It shows you know you have contracts work. You are bound to the contract you've signed. If you don't follow the contract and they have a problem, then you are on the hook for what is written in the contract. If they ask you for something that is not in the contract, then you can do it - but it won't be something they'd be able to hold you to.
In the end, your customer may complain at first; but when they get what they want they'll be happy. Make the contract renegotiation easy for them, and show them that the renegotiation is as much about them getting what they want and keeping them happy as it is ensuring that you are properly paid.
Yes, there is a line where you can say - well, the contract doesn't say that, but we'll do it any way. And that's a line you have to figure out how to walk. But you also cannot simply roll over and say "well, if t
Why are programmers exempt from workmanship standards?
They're not. But they want to be artists or academics that are. It's the Software Engineer vs. Academic Programmer issue.
Colleges focus on Academic Programmers when the business place wants Software Engineers.
One has Workmanship Standards while the other does not.
But we're not talking about a house which is normally something you can quantify as taking x amount of time to a pretty reasonable degree if you've done it before, we're talking about software.
It's no different for the software industry.
I think just about every software contractor has clued into the fact that software requirements change much more rapidly and if I was on the hiring side of the equation I'd be loathe to take on a contractor that didn't want to be paid by the hour, day, or week, and instead wanted to be paid for the full job, as it would say to me that they didn't have the necessary experience to understand the way software is built and what can go wrong because both I and they would be exposed to far too much risk to be healthy.
When requirements change, you change the contract through a renegotiation. If they don't want to change the contract, you don't change what you provide. That's standard practice for contracting. All too often with software the developers do not renegotiate thinking it'll be easy to add, thus allowing feature creep that they are responsible for. A good contractor will be good at controlling the feature creep - this is extremely helpful by forcing contract renegotiations whenever a new feature is requested that was not in the original specification. Add in a contract renegotiation fee for each change, and they'll quickly get the picture that they can't keep changing things.
I had one colleage nearly a decade ago that worked on a project for another manager. She micromanaged things, and would tell him what to change. Our manager didn't really care, or pay much attention to it. She didn't really specify requirements, and in the end it would have been something like having an invisible elephant that you can see and has pink dots without any pink involved. He left the company. She later brought another contractor in and he told her that what she was asking was impossible and the code would have to be restarted from scratch (it was a mess due to her micromanagement). The project died.
Interesting that you're not prepared to guarantee your work. It would make me wary of contracting you as it places the onus on me to ensure that I've throughly tested your code rather than on you. Is this common practice? This entire discussion has either misused the term "contracting", or deliberately glossed over it (by which I don't mean to accuse you specifically, the whole thread has that problem).
When I work under salary, I get paid for projects (along with a certain amount of "keeping the lights on" shit-work, of course). I work unpaid OT if necessary, and cut out early when ahead of schedule. I generally expect (and get) a very flexible schedule so long as I get my tasks done.
When I work as a contractor (and yes, I do both), I get paid for my time. I'll give a good estimate of how long it will take me, but if we run over, you keep paying. Simple as that. Yes, that could potentially lead to abuses by unscrupulous programmers - And they wouldn't get any repeat work for pulling crap like that. Just part of the game: Find a few that work well with/for you, and make them happy enough to stick around.
That depends on the contract, of which there are several ways:
If he contracted them "by project", then the contractor is on the hook for fulfilling all the contract requirements regardless of time; the contractor better hope they estimated it correctly as they're on the hook until the customer signs-off on it. This is essentially a "salaried" contract; but it is not working as a salaried employee.
If he contracted them "hourly", then it is more his issue than the contractors.
However, from the description it sounds like he does "by project" contracting; but there's not really enough information to say.
You don't get to decide when a word is pejorative to a group that's historically been targeted with it.
FYI - it was a word adopted by the homosexual community (circa 1960's and 1970's) to try to replace the term "queer", and to convey a certain message in the process. Over time, though, it has come to be a synonym for "queer" instead.
Just goes to show that one can call something anything they like, but the name will eventually mean the same thing as what was originally given it.
Yeah! It's like saying that 97% of priest believe in god anyway.
This just reveals your wooly thinking. TFA doesn't say "97% of scientists believe in AGW". It's 97% of scientific papers.
True.
i.e. 97% of the ways of examining the question scientifically resulted in a conclusion that AGW is real. Scientific method, not belief.
False.
97% of the papers may have used the same method, or various revisions thereof. There is nothing saying they all used different methodologies. All TFA says is that 97% of published papers and 97% of the surveyed researchers that work on them said AGW is man-made. It says nothing about the quality or validity of those papers, the credentials of the researchers, etc. For all we know, 97% of those researchers were ungrad-students doing research for a professor that required them to assume AGW was man-made.
No other conclusions can be drawn from it.
Except medicare versus private insurance.
You do realize medicare/medicaide is more expensive than private insurance, don't you? Sure, you may not pay for it up front when visiting the doctor or paying for your drugs, but you do pay for it in taxes, along with everyone else.