I remember in middle school Math was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
I remember in middle school English was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
I remember in middle school Science was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
Yet some people did. The point is to expose kids to something new that *some* of them will use again.
You mean Marissa "I was back at work a day after giving birth so everyone should be able to do that" Mayer is friends with the "I'm going to run my company the way it was run when it was a startup"?
In my industry experience the mark of a good leader was one that could see alternative points of view and that possibly, just possibly, not everyone agrees with theirs.
Mayer may have been a half decent CEO if she sat down and thought "Hm, maybe some women don't have an in-office baby sitter and would like to spend time with their children" or "Tele-working works for some of our best and brightest, maybe we shouldn't force them out". Nothing infinitely complex just a realization of different strokes for different folks.
Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.
Rule of Clarity
Developers should write programs as if the most important communication is to the developer who will read and maintain the program, rather than the computer. This rule aims to make code as readable and comprehensible as possible for whoever works on the code in the future.
Rule of Composition
Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.
Rule of Separation
Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and a back-end engine with which that interface communicates. This rule aims to prevent bug introduction by allowing policies to be changed with minimum likelihood of destabilizing operational mechanisms.
Rule of Simplicity
Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.
Rule of Parsimony
Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to write, optimize, and maintain; they are easier to delete when deprecated.
Rule of Transparency
Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.
Rule of Robustness
Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.
Rule of Representation
Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.
Rule of Least Surprise
Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ in a calculator program should always mean 'addition'. This rule aims to encourage developers to build intuitive products that are easy to use.
Rule of Silence
Developers should design programs so that they do not print unnecessary output. This rule aims to allow other programs and developers to pick out the information they need from a program's output without having to parse verbosity.
Rule of Repair
Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
Rule of Economy
Developers should value developer time over machine time, because machine cycles today are
Why is it that it seems the most prolific GoFundMes I see on the local news or shared on Facebook are for Medical Care. Shared by people that are firmly against the Government helping do exactly what they're wanting.
In the same breath the see no Irony in saying: "You libs just want to steal my money to pay for people that need it, but please sponsor Grandma's cancer treaments!!!!"
My wife works in the medical industry and more or less ignores what happens in technology. However this entire time with news stories on NPR and the nightly news she was firmly against 'bro-culture' and sexism in technology.
When the Uber Miami Memo leaked I showed it to her as 'evidence' for the toxic, misogynistic, bro-culture that was everywhere. She read it through twice and then came back with, "Ok, so where's the sexism that people are complaining about?". Every single thing in there she thought was completely reasonable. ("Don't have sex with someone that is above you or in the same group.", "Don't do drugs".)
There is a narrative that a lot of people are pushing and a lot of other people are onboard with defending without sitting down and listening to what some individuals consider offensive and toxic.
Absolutely. The best managers I've had were engineers. The better ones were hands on engineers.
It still doesn't mean it's for everyone. Did Chris hate Tesla or did he hate being a Manager or being a manager at Tesla? Sometimes it just comes down to a clash of A-list personalities. He clearly knows his stuff and knows the direction he wants to go with a project. Jobs may have been hands off with the direction of LLVM while Musk would be more hands on with the direction he wanted Chris to do things.
Way too many co-workers were forced or voluntarily tried the Engineer -> Engineering Leader route and turned out to hate it.
Code, unlike subordinates, does exactly what I tell it to do. If a mechanical design of mine fails it's because I screwed up not because my subordinate did.
I'll make you a wager. You get on any airplane and turn on auto pilot and walk away. Come talk to me after the plane lands itself when it's low on fuel and collect a million dollars.
Because it named its feature "Autopilot", which means it's supposed to be able to pilot itself.
I'll make you a wager. You get on any airplane and turn on auto pilot and walk away. Come talk to me after the plane lands itself when it's low on fuel and collect a million dollars.
When smart phones first came out it was a gold rush to get a 'good enough' device. Looking back at photos from my early phones they were... terrible. The screen cracked if you looked at it. The OS was slow, feature lacking and had a long way to go.
Since then I've stopped buying the latest and greatest and transitioned to 1-2 cycle old products. I tried out a Note 5 and 6 but they really didn't seem that impressive over my Note 4. (As compared to say my Note 4 over my 2010 HTC).
The camera is as good as my old P&S. Accessories are cheap. They've been rooted and ROMs are available.
The same reason my laptop is a 2012 model. It still has decent performance, storage and memory and used costs a fraction of what a new one does.
Long term I see Bitcoin being used as 'currency' the same way gold is used. With the size of the blockchain and amount of time it takes to do much on Bitcoin it's much more useful as a 'gold'.
If Ether has speed advantage it'll start being used for transactions. Hopefully Ether (or competitor) will take off as a digital cash with faster transactions. Imagine trying to checkout of a grocery store with Bitcoin or waiting around with your independent pharmaceutical representative while you wait for Bitcoin confirmations roll in.
So your argument went from: "He's Right" to "You're a dick for pointing out he's not right".
Because he was NOT right. Not only was he not right he was completely wrong. I discovered that 'feature' way back when I was learning UNIX on OS X 10.0.
How does the person that wrote the next gen init glob not know that?
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf/foo/.*" will work the exact same way, no?
almost every single anti systemd post on Slashdot for the last years have been crybullying.
tmpfiles: R!/dir/.* destroys root
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf/foo/.*" will work the exact same way, no?
Again:
Bug Security IT Linux Running "rm -rf/" Is Now Bricking Linux Systems (phoronix.com) 699 Posted by timothy on Monday February 01, 2016 @08:56AM from the now-you-can-troll-harder dept.
An anonymous reader writes:
For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
I remember in middle school Math was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
I remember in middle school English was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
I remember in middle school Science was a requirement to graduate and go to high school. Yet most people that took that class left without knowing anything they ever used again.
Yet some people did. The point is to expose kids to something new that *some* of them will use again.
You mean Marissa "I was back at work a day after giving birth so everyone should be able to do that" Mayer is friends with the "I'm going to run my company the way it was run when it was a startup"?
In my industry experience the mark of a good leader was one that could see alternative points of view and that possibly, just possibly, not everyone agrees with theirs.
Mayer may have been a half decent CEO if she sat down and thought "Hm, maybe some women don't have an in-office baby sitter and would like to spend time with their children" or "Tele-working works for some of our best and brightest, maybe we shouldn't force them out". Nothing infinitely complex just a realization of different strokes for different folks.
Better, a BSD derivative.
The problem is large, monolithic programs.
The technology you should use to solve it is small atomic programs.
Rather than one large program you make a lot of small programs and pipe them through to each other.
Sounds exactly like UNIX:
Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging code that is complex, long, and unreadable.
Developers should write programs as if the most important communication is to the developer who will read and maintain the program, rather than the computer. This rule aims to make code as readable and comprehensible as possible for whoever works on the code in the future.
Developers should write programs that can communicate easily with other programs. This rule aims to allow developers to break down projects into small, simple programs rather than overly complex monolithic programs.
Developers should separate the mechanisms of the programs from the policies of the programs; one method is to divide a program into a front-end interface and a back-end engine with which that interface communicates. This rule aims to prevent bug introduction by allowing policies to be changed with minimum likelihood of destabilizing operational mechanisms.
Developers should design for simplicity by looking for ways to break up program systems into small, straightforward cooperating pieces. This rule aims to discourage developers’ affection for writing “intricate and beautiful complexities” that are in reality bug prone programs.
Developers should avoid writing big programs. This rule aims to prevent overinvestment of development time in failed or suboptimal approaches caused by the owners of the program’s reluctance to throw away visibly large pieces of work. Smaller programs are not only easier to write, optimize, and maintain; they are easier to delete when deprecated.
Developers should design for visibility and discoverability by writing in a way that their thought process can lucidly be seen by future developers working on the project and using input and output formats that make it easy to identify valid input and correct output. This rule aims to reduce debugging time and extend the lifespan of programs.
Developers should design robust programs by designing for transparency and discoverability, because code that is easy to understand is easier to stress test for unexpected conditions that may not be foreseeable in complex programs. This rule aims to help developers build robust, reliable products.
Developers should choose to make data more complicated rather than the procedural logic of the program when faced with the choice, because it is easier for humans to understand complex data compared with complex logic. This rule aims to make programs more readable for any developer working on the project, which allows the program to be maintained.
Developers should design programs that build on top of the potential users' expected knowledge; for example, ‘+’ in a calculator program should always mean 'addition'. This rule aims to encourage developers to build intuitive products that are easy to use.
Developers should design programs so that they do not print unnecessary output. This rule aims to allow other programs and developers to pick out the information they need from a program's output without having to parse verbosity.
Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
Developers should value developer time over machine time, because machine cycles today are
Why is it that it seems the most prolific GoFundMes I see on the local news or shared on Facebook are for Medical Care. Shared by people that are firmly against the Government helping do exactly what they're wanting.
In the same breath the see no Irony in saying: "You libs just want to steal my money to pay for people that need it, but please sponsor Grandma's cancer treaments!!!!"
The future of science and data science needs to be as easy as:
git clone http://whatsamata.edu/medical/...
make
Toss in the read me that you need to have this Siemens medical device attached to USB1 or some other such hardware setup.
Today, lumber yards sell 2x4 being 3/4 of an inch short on all dimensions.
Where are you buying lumber that it's a 3/4" short? It's a 1/2" all around.
A 2x4 is 1.5" by 3.5". A 4x4 is 3.5x3.5. A 2x10 is 1.5x9.5.
My wife works in the medical industry and more or less ignores what happens in technology. However this entire time with news stories on NPR and the nightly news she was firmly against 'bro-culture' and sexism in technology.
When the Uber Miami Memo leaked I showed it to her as 'evidence' for the toxic, misogynistic, bro-culture that was everywhere. She read it through twice and then came back with, "Ok, so where's the sexism that people are complaining about?". Every single thing in there she thought was completely reasonable. ("Don't have sex with someone that is above you or in the same group.", "Don't do drugs".)
There is a narrative that a lot of people are pushing and a lot of other people are onboard with defending without sitting down and listening to what some individuals consider offensive and toxic.
Walmart is on track to become Kmart but they're not there yet. If Walmart did the right things they could crush Amazon.
They opensourced their cloud tools. They have a supply chain management that Amazon wishes it had.
Absolutely. The best managers I've had were engineers. The better ones were hands on engineers.
It still doesn't mean it's for everyone. Did Chris hate Tesla or did he hate being a Manager or being a manager at Tesla? Sometimes it just comes down to a clash of A-list personalities. He clearly knows his stuff and knows the direction he wants to go with a project. Jobs may have been hands off with the direction of LLVM while Musk would be more hands on with the direction he wanted Chris to do things.
He is the main author of LLVM
Way too many co-workers were forced or voluntarily tried the Engineer -> Engineering Leader route and turned out to hate it.
Code, unlike subordinates, does exactly what I tell it to do. If a mechanical design of mine fails it's because I screwed up not because my subordinate did.
You can actually walk away from the autopilot in an aircraft for large periods of time.
Walk away permanently. The discussion is what happens if you become unconscious.
What is the name of the feature?
I'll make you a wager. You get on any airplane and turn on auto pilot and walk away. Come talk to me after the plane lands itself when it's low on fuel and collect a million dollars.
Because it named its feature "Autopilot", which means it's supposed to be able to pilot itself.
I'll make you a wager. You get on any airplane and turn on auto pilot and walk away. Come talk to me after the plane lands itself when it's low on fuel and collect a million dollars.
When smart phones first came out it was a gold rush to get a 'good enough' device. Looking back at photos from my early phones they were... terrible. The screen cracked if you looked at it. The OS was slow, feature lacking and had a long way to go.
Since then I've stopped buying the latest and greatest and transitioned to 1-2 cycle old products. I tried out a Note 5 and 6 but they really didn't seem that impressive over my Note 4. (As compared to say my Note 4 over my 2010 HTC).
The camera is as good as my old P&S. Accessories are cheap. They've been rooted and ROMs are available.
The same reason my laptop is a 2012 model. It still has decent performance, storage and memory and used costs a fraction of what a new one does.
Long term I see Bitcoin being used as 'currency' the same way gold is used. With the size of the blockchain and amount of time it takes to do much on Bitcoin it's much more useful as a 'gold'.
If Ether has speed advantage it'll start being used for transactions. Hopefully Ether (or competitor) will take off as a digital cash with faster transactions. Imagine trying to checkout of a grocery store with Bitcoin or waiting around with your independent pharmaceutical representative while you wait for Bitcoin confirmations roll in.
My dad's first dorm in the 70s were "temporary" barracks they put up after WWII for returning GIs.
They finally tore them down ~2005 to make way for a new building.
So your argument went from: "He's Right" to "You're a dick for pointing out he's not right".
Because he was NOT right. Not only was he not right he was completely wrong. I discovered that 'feature' way back when I was learning UNIX on OS X 10.0.
How does the person that wrote the next gen init glob not know that?
He is right:
Try it. He's not. That has never worked that way. Unix is smart enough to cut the rope for you if you try to hang yourself with that.
root@m6700:/tmp# ls -lah .. .Hello .World /tmp/.* ..
total 8.0K
drwxrwxrwt 2 root root 4.0K Jun 18 22:12 .
drwxr-xr-x 21 root root 4.0K Jun 18 22:12
root@m6700:/tmp# touch
root@m6700:/tmp# mkdir
root@m6700:/tmp# rm -rf
rm: refusing to remove '.' or '..' directory: skipping '/tmp/.'
rm: refusing to remove '.' or '..' directory: skipping '/tmp/..'
root@m6700:/tmp# ls -lah
total 8.0K
drwxrwxrwt 2 root root 4.0K Jun 18 22:14 .
drwxr-xr-x 21 root root 4.0K Jun 18 22:12
tmpfiles: R! /dir/.* destroys root #5644
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
almost every single anti systemd post on Slashdot for the last years have been crybullying.
tmpfiles: R! /dir/.* destroys root
poettering commented on Mar 30: I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?
Again:
Bug Security IT Linux /" Is Now Bricking Linux Systems (phoronix.com) 699
Running "rm -rf
Posted by timothy on Monday February 01, 2016 @08:56AM from the now-you-can-troll-harder dept.
An anonymous reader writes:
For newer systems utilizing UEFI, running rm -rf / is enough to permanently brick your system. While it's a trivial command to run on Linux systems, Windows and other operating systems are also prone to this issue when using UEFI. The problem comes down to UEFI variables being mounted with read/write permissions and when recursively deleting everything, the UEFI variables get wiped too. Systemd developers have rejected mounting the EFI variables as read-only, since there are valid use-cases for writing to them. Mounting them read-only can also break other applications, so for now there is no good solution to avoid potentially bricking your system, but kernel developers are investigating the issue.
The same thing goes for those that wrote an NTTP client. The next big thing is going to be a pretty wrapper on NTTP with moderation, images, etc.
It's what Reddit and Voat users claim they want, completely unfiltered distributed discussion.
There's an API! You can write Bots! It's distributed! No central government can take it down! Free Speech!
Intelligent devs use IDEs
Would that be vim or emacs?
If you need mountain climbers to get there, you can't plant with a tractor.
That's not the engineering solution.
You just need better tractors.