So, we've got one company (Apple) that gets dragged over the coals when they introduce throttling to avoid issues related to hardware wear (Apple throttle to avoid using more current from a battery that can not provide it), now we have Microsoft (maybe) getting dragged over the coals for not including any throttling in order to avoid the rapid heating of the hardware that induces wear on the components. The computer industry is damned if they do and damned if they don't.
"barely tolerate" is when one sits silently through an annoying situation, "bearly tolerate" is when one stands up tall and menacing, then proceeds to tear to shreds whatever they've found annoying.
I like javascript for its event model. I like javascript for it's typeless variables (where non existence is even a state for a "member" variable). I like javascript for its asynchronous nature.
Unfortunately most javascript developers hate javascript and want it to be something that doesn't use events, has strict typing on its variables, and is synchronous. To those I say if you don't like javascript for what it is, don't use javascript.
To preempt the answer "but what else is there to do web development"... I don't know and don't care. I'm not the one hating javascript.
This issue could be that you (the rightful admin level user) walks away from your computer to get another coffee and forget to lock it. While you're brewing, Mr Evil enters the scene and can unlock the App Store preferences panel without knowing your password.
Now I had a look at what is in this panel, there's not much that can be changed in there. The most "harmful" setting may be to save the store password for 15 minutes for purchasing apps.
Some other truly evil things that can be done in there is to change the checking of updates (Ooohhhh) - perhaps setting the "Automatically download apps purchased on other Macs" could be considered a DOS attack as it wouldn't take long to fill up the internal SSD with crap that you had downloaded over the years.
Anyway, it is bad that they have a password box that doesn't give a shit about what password you entered, but in this case not much damage can be done.
I also saw another post that says to disable the update service, dosvc, and bits. So I've done that as well. A quick test showed that my games still work - so I might be safe.
I've got a Windows machine just for playing games. I don't have any sensitive information in the machine, nor do I really care if I have to reinstall at any point (slightly annoying). So, how can I say to Microsoft "Thanks for looking out for me, but I'd rather the extra performance"?
Note that the machine on which I game is from 2015 so the "fix" would have a noticeable slowdown. I've already turned off automatic updates, but this would likely be classes as an emergency update which ignores the settings.
Where I work, I had to negotiate my own salary - nothing was set. I know there are male developers that earn less money than me, I know there are male developers that earn more money than me. There are also female developers that earn less money than me and others that earn more money than me. We've all negotiated our own salaries. Mind you I think some people have obtained their salary not because of their ability to code, but their ability to talk (but that is a different issue).
Perhaps we should just become communists, where everyone gets the same amount for a day's work, regardless of the work we do. I'm sure that would work out great.
If people never reinvented the wheel, we'd still be rolling on stone.
BTW, it isn't always about reinventing the wheel, but rather providing a solution that just solves the problem and doesn't include a bunch stuff that isn't needed. Many javascript developers I've worked with will bring in a third party library to utilise one function in the code. Not only does this increase the resulting code size, it also introduces a dependency on someone else who happens to be maintaining (or not) the package used.
Oh, and to counter your argument. I've worked with way to many people who were happy to end up with 5+MB of compressed javascript for simple applications, simply because they didn't want to "reinvent" any wheels.
I've worked in a team that had a customer, a product owner, a product manager, a project manager, a scrum master, a senior developer, a junior developer, and a tester. I still have no idea why the company wanted to double up on management. The problems had started from the beginning. The product manager spent little to no time obtaining requirements from the customer, they allowed the customer to outsource the designs and then failed to engage them when it came to determining how the designs worked (i.e., the user stories). Note that even without the requirements, the timeframes were already set and provided to the customer. After the "initial" designed were delivered, the product owner and project manager vanished. The requirements gathering was left as a task for the project manager and scrum master; Neither of which wanted to engage the customer to determine the user stories - they made up their own based on how they they thought the app would work.
The developers were introduced to the project. They were shown the designs, and the project manager and scrum master started dividing the "user stories" between the developers. Note that the user stories contained the HEADING ONLY for a feature (i.e., "Show Page" or "Carousel"). The developers were then asked to "estimate" how long it would take to implement each story. The junior developer started to give time frames. I said that it was bullshit. I explained to them that the user stories should cover every aspect of the how the user interacts with the user - not just a title for something they've seen in a design. I told them that this must be a joke. I'll also take this time to say that I was the senior developer (yes a cynical developer who hates management).
Anyway, we were told that we should just start writing the app as their plan was to give the app to the customer often and then "capture" the changes as needed. Needless to say that the project has been going for over half a year, it was due to go to end user testing almost 3 weeks ago, as we're still getting change requests. We also haven't yet got an API to talk to, so everything we have done that requires data has been done with made up data. Note also that the developer that is writing the API is doing it in a way that doesn't allow any collaboration with the app developers due to the fact that there is no time to do it, so once we get the API, we're going to have to go through the code and either change everything that referenced our "fake" data, or have code in place that translates the real API data format into our made up format.
So to summarise, if there is a bad developer in a team the other developers will have to shoulder a bit more work as the code review process should filter out the bad dev's work. But if there is bad management in a team, the product is doomed.
The instinctual traits you've mentioned exist in all (well most) living animals. So perhaps to improve the AI is to start with a foundation of code that can be considered the instinct. Then applied the same nurtural teaching that humans receive a they grow.
When I had upgraded my laptop, I too thought that the keys were very loud. What I discovered was that I was applying a lot more force than required. Now when I type I use much less force than previously and the keys are not loud - note that they are slightly louder than the older keyboard, but not something that is annoying.
The issue is "time to market". Management don't want a solution to a problem that takes weeks to get to market, in the agile world of software development, developers are given a day or two do determine what the problem really is (based off bad requirements), design a solution that meets the requirements, implement the solution, get it through testing, and then move onto the next feature.
Code review is left up to another developer (who is also dealing with the above) to review the diff, and approve or decline the update - usually if it builds, the reviewer will approve for they don't have time to sit down and properly determine what the problem is, and go through the solution in a sufficient level to discover all the issues this introduces.
Perhaps if developers were given the time to develop the solutions in a manner that is secure, and if developers "estimated" the work in a manner that would give them the time to develop secure solutions the software would be better, albeit late to market and over budget.
And yes, juniors who are fresh out of uni are thrown into established projects and are expected to be able to do the first paragraph above with little guidance (for all the other developers are over worked with the above two paragraphs)
Exactly - a good example of a common "poison" that isn't a poison is water. Apart from drowning, many people have died from drinking too much water and causing the blood to thin to a point where it no longer can carry enough oxygen (there's some scientific term for it). This usually occurs in marathon runners and the estimate is about 6 litres per hour (2 buckets to the cock crow for the imperialists). Also on the topic of apples and poison, the seeds of apples contain small amounts of a chemical that can be turned into cyanide in the stomach. Estimates for that is if you chew (well) and swallow around 200 seeds you'll give yourself enough of a dose to cause bad things to happen.
Actually his message was fairly clear in that Ubuntu's primary audience are not the "1337" hackers that like to build their own kernels, or swap desktop environments every other day, but rather those people who just want something other than windows on their system.
So perhaps we should say that you who hide behind the anonymous coward, go and live your life in your mom's basement cursing all the noobs who will destroy Linux for you by wanting a default desktop that doesn't suck balls.
The worst day of the week is not Monday, but it is Tuesday. Think about it...
On Monday you're still coming off the high of the weekend, you're sharing the stories of all the amazing things that occurred over the last two days, you're meeting people you've not seen since the Friday before (usually). Tuesday, however, is a different story... The weekend high is gone, the stories are all told, and the weekend is still so far away - the work week is not even half way through. Wednesday is when things start turning around, you're half way through. The next weekend is in sight. Thursday... almost Friday - likely the second best day of the work week, and then finally Friday is here; You're all ready for 5pm and the weekend.
I think the problem arose due to the fact that if someone links a piece of proprietary code (A) to a GPL'd piece of code (B), piece of code (A) will fall under the GPL (excluding run time linking through process communication mechanisms). It was this issue that resulted in the LGPL (library or lesser gpl) which allowed dynamic linking of (A) to (B) and not have (A) become open source.
If VLC is licensed under the GPL, then any code that Apple attach (ie, the DRM module) would result in the Apple code becoming GPL'd. This was also the essence of Mircosoft's comments on the GPL being viral.
Well, if a Cornell researcher says it, then it must be true. Though if you read what I had written, you will see that what I wrote relies heavily on the mas distribution of the bike to work. A simple test of my theory would be to change the steering mechanism of the bike to invert the direction of the wheel when the bike leans - if it is not the steering, then the balance of the bike would be unchanged.
It is by the design of the steering mechanism that allows a bike to maintain balance even without a rider. A simple test: Stand beside your bike and with the front wheel straight, lean the bike to the left, the front wheel will turn to the left. Now repeat but lean the bike to the right, the front wheel will turn to the right. It is this that reaction that allows the bike to maintain balance when moving because when the bike begins to lean to either the right or left, the bike will automatically steer to the same direction causing the bike to turn. This turning causes a centripetal force around the curve. The bike, which has mass, wants to continue in a straight line and causes the bike to rotate over its own wheels, causing it to straighten up (or to maintain balance). The effect is magnified as the bike slows down due to the momentum of the bike diminishing and can be witnessed as the bike begins to wobble before finally falling due to insufficient momentum to carry its center of mass over the fulcrum.
Slashdot Mirror
So, we've got one company (Apple) that gets dragged over the coals when they introduce throttling to avoid issues related to hardware wear (Apple throttle to avoid using more current from a battery that can not provide it), now we have Microsoft (maybe) getting dragged over the coals for not including any throttling in order to avoid the rapid heating of the hardware that induces wear on the components. The computer industry is damned if they do and damned if they don't.
Actually...
"barely tolerate" is when one sits silently through an annoying situation,
"bearly tolerate" is when one stands up tall and menacing, then proceeds to tear to shreds whatever they've found annoying.
What the carbon emissions of these bullshit "scientific" studies are?
Perhaps we should collect all these "scientists", melt them down and use their juices as a low cost biofuel. At least then they will be contributing.
I like javascript for its event model.
I like javascript for it's typeless variables (where non existence is even a state for a "member" variable).
I like javascript for its asynchronous nature.
Unfortunately most javascript developers hate javascript and want it to be something that doesn't use events, has strict typing on its variables, and is synchronous. To those I say if you don't like javascript for what it is, don't use javascript.
To preempt the answer "but what else is there to do web development"... I don't know and don't care. I'm not the one hating javascript.
(flame on baby)!!!
This issue could be that you (the rightful admin level user) walks away from your computer to get another coffee and forget to lock it. While you're brewing, Mr Evil enters the scene and can unlock the App Store preferences panel without knowing your password.
Now I had a look at what is in this panel, there's not much that can be changed in there. The most "harmful" setting may be to save the store password for 15 minutes for purchasing apps.
Some other truly evil things that can be done in there is to change the checking of updates (Ooohhhh) - perhaps setting the "Automatically download apps purchased on other Macs" could be considered a DOS attack as it wouldn't take long to fill up the internal SSD with crap that you had downloaded over the years.
Anyway, it is bad that they have a password box that doesn't give a shit about what password you entered, but in this case not much damage can be done.
Thanks.
I also saw another post that says to disable the update service, dosvc, and bits. So I've done that as well. A quick test showed that my games still work - so I might be safe.
I've got a Windows machine just for playing games. I don't have any sensitive information in the machine, nor do I really care if I have to reinstall at any point (slightly annoying). So, how can I say to Microsoft "Thanks for looking out for me, but I'd rather the extra performance"?
Note that the machine on which I game is from 2015 so the "fix" would have a noticeable slowdown. I've already turned off automatic updates, but this would likely be classes as an emergency update which ignores the settings.
Where I work, I had to negotiate my own salary - nothing was set. I know there are male developers that earn less money than me, I know there are male developers that earn more money than me. There are also female developers that earn less money than me and others that earn more money than me. We've all negotiated our own salaries. Mind you I think some people have obtained their salary not because of their ability to code, but their ability to talk (but that is a different issue).
Perhaps we should just become communists, where everyone gets the same amount for a day's work, regardless of the work we do. I'm sure that would work out great.
If people never reinvented the wheel, we'd still be rolling on stone.
BTW, it isn't always about reinventing the wheel, but rather providing a solution that just solves the problem and doesn't include a bunch stuff that isn't needed. Many javascript developers I've worked with will bring in a third party library to utilise one function in the code. Not only does this increase the resulting code size, it also introduces a dependency on someone else who happens to be maintaining (or not) the package used.
Oh, and to counter your argument. I've worked with way to many people who were happy to end up with 5+MB of compressed javascript for simple applications, simply because they didn't want to "reinvent" any wheels.
I've worked in a team that had a customer, a product owner, a product manager, a project manager, a scrum master, a senior developer, a junior developer, and a tester. I still have no idea why the company wanted to double up on management. The problems had started from the beginning. The product manager spent little to no time obtaining requirements from the customer, they allowed the customer to outsource the designs and then failed to engage them when it came to determining how the designs worked (i.e., the user stories). Note that even without the requirements, the timeframes were already set and provided to the customer. After the "initial" designed were delivered, the product owner and project manager vanished. The requirements gathering was left as a task for the project manager and scrum master; Neither of which wanted to engage the customer to determine the user stories - they made up their own based on how they they thought the app would work.
The developers were introduced to the project. They were shown the designs, and the project manager and scrum master started dividing the "user stories" between the developers. Note that the user stories contained the HEADING ONLY for a feature (i.e., "Show Page" or "Carousel"). The developers were then asked to "estimate" how long it would take to implement each story. The junior developer started to give time frames. I said that it was bullshit. I explained to them that the user stories should cover every aspect of the how the user interacts with the user - not just a title for something they've seen in a design. I told them that this must be a joke. I'll also take this time to say that I was the senior developer (yes a cynical developer who hates management).
Anyway, we were told that we should just start writing the app as their plan was to give the app to the customer often and then "capture" the changes as needed. Needless to say that the project has been going for over half a year, it was due to go to end user testing almost 3 weeks ago, as we're still getting change requests. We also haven't yet got an API to talk to, so everything we have done that requires data has been done with made up data. Note also that the developer that is writing the API is doing it in a way that doesn't allow any collaboration with the app developers due to the fact that there is no time to do it, so once we get the API, we're going to have to go through the code and either change everything that referenced our "fake" data, or have code in place that translates the real API data format into our made up format.
So to summarise, if there is a bad developer in a team the other developers will have to shoulder a bit more work as the code review process should filter out the bad dev's work. But if there is bad management in a team, the product is doomed.
The instinctual traits you've mentioned exist in all (well most) living animals. So perhaps to improve the AI is to start with a foundation of code that can be considered the instinct. Then applied the same nurtural teaching that humans receive a they grow.
When I had upgraded my laptop, I too thought that the keys were very loud. What I discovered was that I was applying a lot more force than required. Now when I type I use much less force than previously and the keys are not loud - note that they are slightly louder than the older keyboard, but not something that is annoying.
The issue is "time to market". Management don't want a solution to a problem that takes weeks to get to market, in the agile world of software development, developers are given a day or two do determine what the problem really is (based off bad requirements), design a solution that meets the requirements, implement the solution, get it through testing, and then move onto the next feature.
Code review is left up to another developer (who is also dealing with the above) to review the diff, and approve or decline the update - usually if it builds, the reviewer will approve for they don't have time to sit down and properly determine what the problem is, and go through the solution in a sufficient level to discover all the issues this introduces.
Perhaps if developers were given the time to develop the solutions in a manner that is secure, and if developers "estimated" the work in a manner that would give them the time to develop secure solutions the software would be better, albeit late to market and over budget.
And yes, juniors who are fresh out of uni are thrown into established projects and are expected to be able to do the first paragraph above with little guidance (for all the other developers are over worked with the above two paragraphs)
Exactly - a good example of a common "poison" that isn't a poison is water. Apart from drowning, many people have died from drinking too much water and causing the blood to thin to a point where it no longer can carry enough oxygen (there's some scientific term for it). This usually occurs in marathon runners and the estimate is about 6 litres per hour (2 buckets to the cock crow for the imperialists). Also on the topic of apples and poison, the seeds of apples contain small amounts of a chemical that can be turned into cyanide in the stomach. Estimates for that is if you chew (well) and swallow around 200 seeds you'll give yourself enough of a dose to cause bad things to happen.
You forgot the "H" for the heterosexual community. If they want to be inclusive, they really should include everyone.
Actually his message was fairly clear in that Ubuntu's primary audience are not the "1337" hackers that like to build their own kernels, or swap desktop environments every other day, but rather those people who just want something other than windows on their system.
So perhaps we should say that you who hide behind the anonymous coward, go and live your life in your mom's basement cursing all the noobs who will destroy Linux for you by wanting a default desktop that doesn't suck balls.
Perhaps we should just ban pink and blue - fuck it, let's ban all colours (an even colors). Let the whingers wear shades of grey and be miserable.
The worst day of the week is not Monday, but it is Tuesday. Think about it...
On Monday you're still coming off the high of the weekend, you're sharing the stories of all the amazing things that occurred over the last two days, you're meeting people you've not seen since the Friday before (usually). Tuesday, however, is a different story... The weekend high is gone, the stories are all told, and the weekend is still so far away - the work week is not even half way through. Wednesday is when things start turning around, you're half way through. The next weekend is in sight. Thursday... almost Friday - likely the second best day of the work week, and then finally Friday is here; You're all ready for 5pm and the weekend.
Windows setup: http://www.4shared.com/file/ya...
Mac dmg: http://www.4shared.com/file/QH...
Source tarball: http://www.4shared.com/archive...
md5sums have be checked against those listed at http://truecryptcheck.wordpres...
I heard on the internets that version 6 of Emacs was going to be called VI
I think the problem arose due to the fact that if someone links a piece of proprietary code (A) to a GPL'd piece of code (B), piece of code (A) will fall under the GPL (excluding run time linking through process communication mechanisms). It was this issue that resulted in the LGPL (library or lesser gpl) which allowed dynamic linking of (A) to (B) and not have (A) become open source.
If VLC is licensed under the GPL, then any code that Apple attach (ie, the DRM module) would result in the Apple code becoming GPL'd. This was also the essence of Mircosoft's comments on the GPL being viral.
Solving problems (programming) can help improve problem solving skills.
Bisecting is also a way of killing bugs - or perhaps Bisecting is when you act like an insect that goes both ways.
Well, if a Cornell researcher says it, then it must be true. Though if you read what I had written, you will see that what I wrote relies heavily on the mas distribution of the bike to work. A simple test of my theory would be to change the steering mechanism of the bike to invert the direction of the wheel when the bike leans - if it is not the steering, then the balance of the bike would be unchanged.
It is by the design of the steering mechanism that allows a bike to maintain balance even without a rider. A simple test: Stand beside your bike and with the front wheel straight, lean the bike to the left, the front wheel will turn to the left. Now repeat but lean the bike to the right, the front wheel will turn to the right. It is this that reaction that allows the bike to maintain balance when moving because when the bike begins to lean to either the right or left, the bike will automatically steer to the same direction causing the bike to turn. This turning causes a centripetal force around the curve. The bike, which has mass, wants to continue in a straight line and causes the bike to rotate over its own wheels, causing it to straighten up (or to maintain balance). The effect is magnified as the bike slows down due to the momentum of the bike diminishing and can be witnessed as the bike begins to wobble before finally falling due to insufficient momentum to carry its center of mass over the fulcrum.