Taskwarrior is fantastic. You can access the data from all of your devices, and although it will require some effort the upside is you have full control over all of your data, as well as a significant level of control over how tasks are prioritized, tagged, annotated, etc.
The server is a bit of a pain to set up, but it's worth it.
This is not user location data, despite what the summary states. It is data about the cell tower the user phone is associated with, *when the user makes a call*. Yes, this can give you some level of location data for the user, but the location precision is quite poor, and it does not exist when you are not using the phone.
The US already has this exact regulation, and has had it for over a year. This is a non-story, other than China is coming into alignment with the EU and US on drone policy (where the EU was long before the US).
Yes this is exactly the same in most countries - china is even later than the US, which was *super late* in this kind of regulation. The USA has an identical regulation for 250g to 25Kg (over 25Kg requires licensing, not just registration).
I for one am not that thrilled about drones that have a mass of 20Kg only needing registration....
They're doing a completely unrelated *test* of a drone in New Jersey, which has absolutely zero to do with the hurricane and isn't going to be helping anyone in the actual disaster area.
No responsible physician answered this poll, because they could lose their license. You may not render any judgement on the physical health of an individual whom you have not personally examined - doing so is beyond irresponsible, and actionable by your licensing board.
NSF does not actually do things - they *fund* other people who do things. NSF also cannot patent anything (nor can any part of the government), and the submitted patent for NetEgg has nothing to do with NSF.
There is absolutely nowhere in the RFC that it specifies that the challenge ACK rate limiter should be a single global limiter. Claiming that the Linux implementation is "faithful" is mostly true, in a naive way, but a non-broken implementation would *also* be a "faithful" implementation of the RFC.
In pre-Trump world I would have found this amusing, but now there is a strong aspect of troubling to it (not belonging wholly to the subject to be fair, as an artifact of our times). David Bennahum is at best in his mid-40s (from his LinkedIn page), and thus has NO FUCKING CLUE what coding was like in the 50s. People did not sit at their terminals and write COBOL programs. In the 50s we sat at our terminals and ground out punch cards (not in COBOL...that would have been way too easy - COBOL didn't even appear until 1959, and even for people with ridiculous amount of money, 1961-62 as a practical matter), which were then fed to the "minicomputer" (at best) by a legion of "priests" who were in control of the machine.
The "Priests" in this system were less than even the difference between car designers and auto mechanics - they didn't know how to write code or make the computer work, they were just the gatekeepers to the input to a SUPER VALUABLE system. They existed because the system was in fact unbelievably expensive, and was meted out to users according to the needs of the corporation (owner). Hard pressed, a good auto mechanic could almost certainly build a functional automobile - a "priest" could not build a computer, or even explain how it worked (nor should they - that was not a requirement of the job, nor should it have been).
I would believe that there are some strong feelings about CS teaching to our youth, and many of them are probably well founded. (I'm sure plenty are not, but this is how life works). However, the quoted piece is marketing schlock, and is clearly a way to push a product, not even an agenda (the agenda would advocate for many products, but clearly theirs is the only option here).
There are over 650 entities across the globe that can sign SSL certificates for any domain they want. For less than 6 figures USD you can buy an intermediate cert yourself. Not to mention that unless you ask for something like google.com or something similarly high profile, you can just *buy* a site certificate for sites you don't own from less-than-thorough CAs.
How is it special that Bluecoat can sign their own (maybe - assuming Symantec is not to be believed on who had the keys)? Most of the government actors they sell their products to *already* have their own CA that OSes and browsers trust, and thus can just use their own.
The global CA system is a hopelessly broken part of SSL for web sites (SSL is fine in general, and if you're using it to secure your own sessions with your own certs, everything is basically good otherwise), and being shocked about some non-story is not helping. Using SSL on the web means that you have placed permanent and absolute trust in everyone who controls a root, and everyone who they ever issued an intermediate signing cert to. That's not sane.
Well, yes, I actually do think that someone (IBM) should be able to sue Oracle for using SQL, in the abstract. In reality when IBM offered SQL to ANSI they agreed to make it zero license. Of course, all users of SQL add non-standard extensions to make it not-really-interoperable, in order to keep their own edge. Those extensions are often not licensed to third parties (although sometimes are, and those licenses end up making strange movements over time based on mergers and such, which actually often ends up with them being opened, or they find their way into future standards with zero-license clauses).
The AT&T SVR4 API was in fact licensed by Sun (and HP and IBM), at considerable expense. These licenses continued to be paid until Novell released the SVR4 license and Unix name to The Open Group. SCO has attempted to collect on later SYSV licenses, with little success, but that is only because most forks were legal variants of SYSV made before the revisions that SCO controlled.
It's not different from Android, and historically APIs have been licensed.
The "menu analogy" didn't make sense to me either. The power plug analogy was better, since (unlike a menu) that really is an interface. It lets you use power from any source (solar, wind, coal, nuke) to power any device (computer, TV, microwave oven). You can swap any source or device in-or-out as long as it adheres to the spec (analogous to the API).
The power plug analogy also demonstrates why copyrights/patents on interfaces are a really bad idea. If everyone need a separate plug for every power source / device combination, then our walls would be covered with outlets, and you would need to hire an electrician every time you bought a new lamp.
This falls flat in reality. Many devices have their own power receptacles on device-end (micro-USB, firewire, etc.) and those are all licensed. The in-wall receptacle in various countries (and in this case we consider the US) were also once licensed, but most of those have expired at this point.
If Oracle wants to demand licensing fees on the Java API, it's hard to argue that they shouldn't be allowed to do so. We might argue this is really stupid, economically, but the legal equivalencies are not hard to find. Even more importantly at issue in this case is that Google has taken the Java APIs, but not actually implemented Java - they've used these APIs to do something else entirely. This is somewhat akin to taking an L5-15 and only delivering 10 amps. Sure it works most of the time, but it's not the same.
This money cannot be used by Tesla, there is zero operating cash acquired by people pre-ordering a product.
When (and *only* when) the cars are actually delivered, depending on various accounting rules and commercial regulations, Tesla *may* be able to profit from any interest made on these payments. These payments express interest and are an excellent way for Tesla to factor real production needs (more than just adding your name to a list), but the actual monetary value to Tesla in the short term is nil.
RJpoint5 is in fact not a standard, but a vendor play, which is why it is expensive. It works fine, but volume isn't the problem so much as the incredible licensing fees.
I *think* he wants a USB widget that attaches to an ethernet line and plugs into a PC so he can reboot it, but hell if I know.
Oh, I thought they wanted a USB power source that they could remotely cycle for a "reboot" of something powered via USB. Of course, you could just as easily be right.
This is really 100% a logistics problem determined by both the size, layout, and "unusualness" of the establishment. For giant warehouses, dangerous manufacturing facilities, places with rail lines on site, etc., with multiple gates and physical building doors, the reason you don't call 911 is because you probably can't tell them anything useful about how to efficiently get to you, and once you call 911 the next call from the people who *do* know is possibly not going to go well (as they will instead try to reroute the emergency team you led to the wrong place, except maybe no one can actually figure out where they currently are in relation to where they should be). For smaller buildings or those that are more familiar (or with regular layouts like office structures with numbered floors and offices), the first call being to 911 is absolutely the right thing.
If a company has published internal documents and pamphlets that say to call security, and specifically to *NOT* call 911, then that is because they are either a) guilty of gross negligence (very unlikely), or b) have a plan in place to address issues in a way that is most efficient - sometimes developed in partnership with the local emergency services - and have qualified emergency response personnel on staff.
This is not programming. It's *definitely* not developing. It *might* be coding, although if that's the case then that should be regarded as an insult to someone.
"Coding" by googling and copying code is no better than monks who couldn't read who could copy important texts by copying the "pictures" (letters) before the printing press existed. Except this has significantly less value, and more danger - the internet is not magically full of "better" information on writing code than it is about anything else. The vast majority of the answers to the questions you will google will either be flat out wrong, or intentionally naive/trivial, as they are probably (at best) trying to teach a concept outside of the context of whatever you are doing. Without greater understanding you won't be in a position to know that the answer you found isn't the answer you want.
And of course this is how you write apps with horrible security vulnerabilities.
Please, deliver me from the legion of "coders" who take this seriously.
Slashdot Mirror
Since when did papers on Arxiv get a claim of peer review? I mean, ok, I guess I read it. So sure.
Taskwarrior is fantastic. You can access the data from all of your devices, and although it will require some effort the upside is you have full control over all of your data, as well as a significant level of control over how tasks are prioritized, tagged, annotated, etc.
The server is a bit of a pain to set up, but it's worth it.
This is not user location data, despite what the summary states. It is data about the cell tower the user phone is associated with, *when the user makes a call*. Yes, this can give you some level of location data for the user, but the location precision is quite poor, and it does not exist when you are not using the phone.
Getting cell tower association data requires a court order, just like call detail record (CDR) data does (it's basically in the CDR data for mobile).
Lovely meaningless diatribe.
The US already has this exact regulation, and has had it for over a year. This is a non-story, other than China is coming into alignment with the EU and US on drone policy (where the EU was long before the US).
Yes this is exactly the same in most countries - china is even later than the US, which was *super late* in this kind of regulation. The USA has an identical regulation for 250g to 25Kg (over 25Kg requires licensing, not just registration).
I for one am not that thrilled about drones that have a mass of 20Kg only needing registration....
Why is this a story? This requirement already exists in the US.
They're doing a completely unrelated *test* of a drone in New Jersey, which has absolutely zero to do with the hurricane and isn't going to be helping anyone in the actual disaster area.
"Informal Internet Poll"? Really?
No responsible physician answered this poll, because they could lose their license. You may not render any judgement on the physical health of an individual whom you have not personally examined - doing so is beyond irresponsible, and actionable by your licensing board.
NSF does not actually do things - they *fund* other people who do things. NSF also cannot patent anything (nor can any part of the government), and the submitted patent for NetEgg has nothing to do with NSF.
There is absolutely nowhere in the RFC that it specifies that the challenge ACK rate limiter should be a single global limiter. Claiming that the Linux implementation is "faithful" is mostly true, in a naive way, but a non-broken implementation would *also* be a "faithful" implementation of the RFC.
If they were granted permission to test at Yuma, that is all the approval they needed to do so under the existing military flight privileges.
In pre-Trump world I would have found this amusing, but now there is a strong aspect of troubling to it (not belonging wholly to the subject to be fair, as an artifact of our times). David Bennahum is at best in his mid-40s (from his LinkedIn page), and thus has NO FUCKING CLUE what coding was like in the 50s. People did not sit at their terminals and write COBOL programs. In the 50s we sat at our terminals and ground out punch cards (not in COBOL...that would have been way too easy - COBOL didn't even appear until 1959, and even for people with ridiculous amount of money, 1961-62 as a practical matter), which were then fed to the "minicomputer" (at best) by a legion of "priests" who were in control of the machine.
The "Priests" in this system were less than even the difference between car designers and auto mechanics - they didn't know how to write code or make the computer work, they were just the gatekeepers to the input to a SUPER VALUABLE system. They existed because the system was in fact unbelievably expensive, and was meted out to users according to the needs of the corporation (owner). Hard pressed, a good auto mechanic could almost certainly build a functional automobile - a "priest" could not build a computer, or even explain how it worked (nor should they - that was not a requirement of the job, nor should it have been).
I would believe that there are some strong feelings about CS teaching to our youth, and many of them are probably well founded. (I'm sure plenty are not, but this is how life works). However, the quoted piece is marketing schlock, and is clearly a way to push a product, not even an agenda (the agenda would advocate for many products, but clearly theirs is the only option here).
Since when has Symantec (or any CA) been trustworthy?
Why do you place any trust in them? Do you know who their directors are? Do you trust these people? Why?
There are over 650 entities across the globe that can sign SSL certificates for any domain they want. For less than 6 figures USD you can buy an intermediate cert yourself. Not to mention that unless you ask for something like google.com or something similarly high profile, you can just *buy* a site certificate for sites you don't own from less-than-thorough CAs.
How is it special that Bluecoat can sign their own (maybe - assuming Symantec is not to be believed on who had the keys)? Most of the government actors they sell their products to *already* have their own CA that OSes and browsers trust, and thus can just use their own.
The global CA system is a hopelessly broken part of SSL for web sites (SSL is fine in general, and if you're using it to secure your own sessions with your own certs, everything is basically good otherwise), and being shocked about some non-story is not helping. Using SSL on the web means that you have placed permanent and absolute trust in everyone who controls a root, and everyone who they ever issued an intermediate signing cert to. That's not sane.
Well, yes, I actually do think that someone (IBM) should be able to sue Oracle for using SQL, in the abstract. In reality when IBM offered SQL to ANSI they agreed to make it zero license. Of course, all users of SQL add non-standard extensions to make it not-really-interoperable, in order to keep their own edge. Those extensions are often not licensed to third parties (although sometimes are, and those licenses end up making strange movements over time based on mergers and such, which actually often ends up with them being opened, or they find their way into future standards with zero-license clauses).
The AT&T SVR4 API was in fact licensed by Sun (and HP and IBM), at considerable expense. These licenses continued to be paid until Novell released the SVR4 license and Unix name to The Open Group. SCO has attempted to collect on later SYSV licenses, with little success, but that is only because most forks were legal variants of SYSV made before the revisions that SCO controlled.
It's not different from Android, and historically APIs have been licensed.
The "menu analogy" didn't make sense to me either. The power plug analogy was better, since (unlike a menu) that really is an interface. It lets you use power from any source (solar, wind, coal, nuke) to power any device (computer, TV, microwave oven). You can swap any source or device in-or-out as long as it adheres to the spec (analogous to the API).
The power plug analogy also demonstrates why copyrights/patents on interfaces are a really bad idea. If everyone need a separate plug for every power source / device combination, then our walls would be covered with outlets, and you would need to hire an electrician every time you bought a new lamp.
This falls flat in reality. Many devices have their own power receptacles on device-end (micro-USB, firewire, etc.) and those are all licensed. The in-wall receptacle in various countries (and in this case we consider the US) were also once licensed, but most of those have expired at this point.
If Oracle wants to demand licensing fees on the Java API, it's hard to argue that they shouldn't be allowed to do so. We might argue this is really stupid, economically, but the legal equivalencies are not hard to find. Even more importantly at issue in this case is that Google has taken the Java APIs, but not actually implemented Java - they've used these APIs to do something else entirely. This is somewhat akin to taking an L5-15 and only delivering 10 amps. Sure it works most of the time, but it's not the same.
This money cannot be used by Tesla, there is zero operating cash acquired by people pre-ordering a product.
When (and *only* when) the cars are actually delivered, depending on various accounting rules and commercial regulations, Tesla *may* be able to profit from any interest made on these payments. These payments express interest and are an excellent way for Tesla to factor real production needs (more than just adding your name to a list), but the actual monetary value to Tesla in the short term is nil.
RJpoint5 is in fact not a standard, but a vendor play, which is why it is expensive. It works fine, but volume isn't the problem so much as the incredible licensing fees.
I *think* he wants a USB widget that attaches to an ethernet line and plugs into a PC so he can reboot it, but hell if I know.
Oh, I thought they wanted a USB power source that they could remotely cycle for a "reboot" of something powered via USB. Of course, you could just as easily be right.
Horray for clarity.
It's clear that what the OP meant was the ubiquitous bricks for power delivery.
Of course, nothing else is clear, so who the hell knows what they actually want...
1998 wants its' concern over "cool" TLDs back.
Sure, it's an organization pain for a minor number of services, but it's hardly a travesty that warrants any coverage.
Absolutely true. Now name a desktop OS that had those features at the time.
Linux is barely even a desktop OS *now*, the idea that you would compare it to desktop OSes in the 90s is amusing at best.
This is really 100% a logistics problem determined by both the size, layout, and "unusualness" of the establishment. For giant warehouses, dangerous manufacturing facilities, places with rail lines on site, etc., with multiple gates and physical building doors, the reason you don't call 911 is because you probably can't tell them anything useful about how to efficiently get to you, and once you call 911 the next call from the people who *do* know is possibly not going to go well (as they will instead try to reroute the emergency team you led to the wrong place, except maybe no one can actually figure out where they currently are in relation to where they should be). For smaller buildings or those that are more familiar (or with regular layouts like office structures with numbered floors and offices), the first call being to 911 is absolutely the right thing.
If a company has published internal documents and pamphlets that say to call security, and specifically to *NOT* call 911, then that is because they are either a) guilty of gross negligence (very unlikely), or b) have a plan in place to address issues in a way that is most efficient - sometimes developed in partnership with the local emergency services - and have qualified emergency response personnel on staff.
This is not programming. It's *definitely* not developing. It *might* be coding, although if that's the case then that should be regarded as an insult to someone.
"Coding" by googling and copying code is no better than monks who couldn't read who could copy important texts by copying the "pictures" (letters) before the printing press existed. Except this has significantly less value, and more danger - the internet is not magically full of "better" information on writing code than it is about anything else. The vast majority of the answers to the questions you will google will either be flat out wrong, or intentionally naive/trivial, as they are probably (at best) trying to teach a concept outside of the context of whatever you are doing. Without greater understanding you won't be in a position to know that the answer you found isn't the answer you want.
And of course this is how you write apps with horrible security vulnerabilities.
Please, deliver me from the legion of "coders" who take this seriously.