It only took me a hour to learn the openscad language and a couple more to be fluent. One day later I have a handy library of shapes for making parametric electrical enclosures.
The ease of using openscad is making me interested in getting a 3D printer.
The chips you are using are created using SystemVerilog or VHDL mostly. OCAML is used a lot to formally verify the logic in those chips and C code. OpenSCAD is an excellent physical design language for creating 3D shapes with code rather than poking your mouse at a 3D UI.
There is no small number of traditional cab drivers who are driving for Uber and Lyft.
The driver and car may vary, but it's the app and response time that makes it convenient for the user. My Lyft ride on Thursday in Santa Clara arrived 20 seconds after tapping the request button.
Then machine "B" gets nailed by every LEO from Interpol down to the local dogcatcher.
The best way is to have an account with a VPN service, and use TOR in front. The VPN's IP space will be viewed as dodgy, but not outright banned like all TOR nodes tend to be.
I wasn't proposing that as a way to conduct illegal activities. I was proposing that as a way of getting around your employers TOR block. Practically you only need machine A for most situations.
I presume the enterprising TOR user could set up a couple of machines A and B somwhere on the internetz to act as a personal TOR entry and exit point. VPN to A. A TORs to B. B talks to the internetz.
Commercial, passenger, aviation has cost issues for just about everything. WiFi might be easier to cost control than most other items but maybe the real answer is to have a lot less passenger aviation. Companies paying to fly people all about on business does not bode well for the cost of the product to the buyer.
I fly about on business because it gets stuff done. The cost is moot compared to a 10 billion dollar factory going idle.
AC made an assertion he knows that he or she doesn't know. It was a lie. I know it to be a lie because I know the circuit. Several other people on this planet know enough to know it is a lie. Other people don't know, which is just how the universe works.
If you are interested in testing random numbers, you are welcome to buy my book on the subject when I finish writing it in about 20 years.
I'd like to see clear(er) written guidelines for how say customer data should be cared for. And because their may be valid reasons to deviate from the guidelines, perhaps request that the reason for the deviations be written down by the organization and supplied on request to the FTC.
Oh, you mean like when a company agrees to process credit card transactions the written guidelines that dictate PCI-DSS 3.0 compliance?
(Sorry, but in the example provided in TFS, it sure as shit seems pretty cut and dry)
Can you explain how PCI-DSS 3.0 stops anything getting hacked? You know the Target and Home Depot systems were PCI compliant right?
The NIST stuff isn't so awful, but it's not in a form that's very useful. It's lots of little specs that don't fit together into a system. However it contains very useful specs on means for an organization to protect itself. This is good.
This is a solvable problem, but the PCI specs are a barrier to uniform adoption of something effective.
>better performing for less Enterprise-class hardware? Maybe if you're overpaying for it. If you owned the same hardware that amazon does, it would be cheaper and faster than running it on amazon's VMs. Faster for the obvious reason that you're running on bare metal and not inside a VM, and cheaper because Amazon wouldn't profit if their income from renting VMs was less than what they spent on hardware. Check the price of renting a big VM for 3 years versus buying the equivalent real hardware.
None of this is to suggest that there aren't other benefits to using VMs. Like you said, resilience and monitoring. Someone else's grunts are dealing with the hardware instead of you.
If you do it right, you should be able to guarantee some base load that will keep some computers busy. Buy those and run the system on it. Then use the cloudy servers to scale up as variable load happens. The cloud stuff isn't cheaper unless you are avoiding paying for idle hardware.
You can't tell where your cloud computing is hosted. Any host can delegate to some other host. So Vendor A with well paid shiny sales people sells cloud hosting. Vendor A outsources the physical part of the cloud to Vendor B who is a bit cheaper with slightly less well paid sales people. Vendor A cashes the difference. Vendor B outsources to vendor C in China who is cheaper still. Vendor B cashes the difference. C -> D D -> E Repeat a few times until all the world's cloud computing it running on a server in a cupboard in Kazakhstan.
If the online payment service appears to the end customer to be on your website, then a malicious hacker could replace your website with a version which harvests credit cards. I realize that PayPal (and possibly Stripe) successfully lobbied for their embedded form service to be excluded from the more rigorous PCI auditing category (forgive the ambiguity, it's been awhile since I dealt with PCI compliance), but that's politics, not security. I wouldn't count on it lasting, either.
Nevertheless, it's the right thing to do from a practical standpoint. The higher audit levels would require every mom and pop website software to be audited. Encapsulating in a window served from their servers is the right way to shield customers from the mess that is random website design and actually get it out there. If you had the higher audit levels, it wouldn't get used at all and we would have people typing thier card data into nasty php scripts written by a friend of the proprietor's daughter.
There is little in the PCI specs that adds to the security of card transactions. These are the same people who've held back the adoption of EMV for a decade and the specs focus on vendor 'process' more than things that matter, like defense in depth system design. We have a shiny new EMV and NFC compatible card reader and it has a big sticker on the bottom proclaiming it to use triple DES, like that's a good thing. Look a bit deeper and it's 1024 RSA for the key agreement and some mode of DES for the transactions. The 1990s called and wants its crypto back. This is written in some software on a microprocessor in the box. I have no way of knowing how crappy that software is, except my years of experience in secure system design that tells me it'll have more holes than Swiss cheese. But it would violate PCI-DSS rules for me to open the box and take a look inside.
Right. I did a little research that suggested the payment processor wasn't incompetent when it came to security. However the average yarn store owner wouldn't know how to do that.
She can tell bad yarn a mile off though. We already dropped a couple of suppliers who moved their manufacturing to China and the quality dropped. However don't take that to mean all yarn that's been through China is bad. Chinese yarn processors apply the superwash process to some quality yarns.
The card processor is not supposed to hang onto card data, but we have no way of really knowing. There are limits to what you can achieve because you are forced to rely on a number of external organizations (banks, networks, payment card processors, equipment vendors etc.) that you have not much choice in.
If PCI-DSS specs were well architected and written, payment card equipment would be more secure and enable integration with point of sale systems without passing sensitive information through the PoS, thus reducing the attack surface.
If the business grows large enough, we would hire some serious security experts and developers to develop our own secure payment processing. But the business couldn't support it right now and I get paid much more by working as a security expert for a large semiconductor corporation.
You have a choice, you (the payment card industry) self-regulate, or the government steps in and tells you how to do it. If you don't like the PCI-DSS, try to imagine what government's version would be.
Imagine if they farmed the spec writing out to a list of likely suspect techy companies who have shown themselves able to create secure specs. They couldn't do worst than PCI-DSS or the government.
But in this case it's not the credit card information that anybody cares about -- it's the customer data.
Imagine that you could tell somebody's deepest-darkest secrets based on what kinds of yarns they looked at! You'd now have to protect the core of your business data (that's a lot harder to meaningfully encrypt when you have to spend most of your time actually processing that data).
dom
Yup. If you're planning to process sensitive customer data, it's not enough to expect an IT department to do it. You need to make procedural and cryptographic security the core of your business and put practitioners of those disciplines in senior positions in the company. If not, you and your customers are just lambs to the slaughter.
We don't attach people's names to transactions unless they ask for it. So the yarn-dark-secrets link is relatively safe from the 2000 or so hacking attempts that get made on our little server every day.
I think I could make a secure system for handling customer data, but it would be a full time job and I already have a job.
Anyone trying to use this extremely common words combination will have to pay royalties?
You seriously have absolutely no idea how trademarks work?
I do have a bit of a clue. I have a couple of trademarks. I am surprised that a watch vendor got a trademark on a phrase used in promotional performances by another watch vendor. Maybe lawyers will be sharpening their quills.
Slashdot Mirror
that a Fender Twin Reverb might be rather inefficient, too?
I upgraded to the more efficient Mesa Mark V 25.
With all the energy I'm saving, I should be rich.
It only took me a hour to learn the openscad language and a couple more to be fluent. One day later I have a handy library of shapes for making parametric electrical enclosures.
The ease of using openscad is making me interested in getting a 3D printer.
The chips you are using are created using SystemVerilog or VHDL mostly.
OCAML is used a lot to formally verify the logic in those chips and C code.
OpenSCAD is an excellent physical design language for creating 3D shapes with code rather than poking your mouse at a 3D UI.
There is no small number of traditional cab drivers who are driving for Uber and Lyft.
The driver and car may vary, but it's the app and response time that makes it convenient for the user.
My Lyft ride on Thursday in Santa Clara arrived 20 seconds after tapping the request button.
> then you must know what parenting techniques work to eliminate the symptoms. Elucidate us.
It's not parenting. It's schooling. Stop putting them in a school context that expects them to sit still for 6 hours a day.
Then machine "B" gets nailed by every LEO from Interpol down to the local dogcatcher.
The best way is to have an account with a VPN service, and use TOR in front. The VPN's IP space will be viewed as dodgy, but not outright banned like all TOR nodes tend to be.
I wasn't proposing that as a way to conduct illegal activities. I was proposing that as a way of getting around your employers TOR block. Practically you only need machine A for most situations.
You could read the paper and see if the data speaks for itself.
Yes. It's just an indirection to prevent attacks or filters at the entry and exit points.
I presume the enterprising TOR user could set up a couple of machines A and B somwhere on the internetz to act as a personal TOR entry and exit point. VPN to A. A TORs to B. B talks to the internetz.
Hey now, my GPU that consumes 200 watts for any random 3D application is GREEN.
I mean, literally, it's covered with stickers that are the color green. I'm saving the environment.
Phew! We're saved!
I came here expecting a discussion about carbon emissions resulting from NVIDIA cards.
Commercial, passenger, aviation has cost issues for just about everything. WiFi might be easier to cost control than most other items but maybe the real answer is to have a lot less passenger aviation. Companies paying to fly people all about on business does not bode well for the cost of the product to the buyer.
I fly about on business because it gets stuff done. The cost is moot compared to a 10 billion dollar factory going idle.
Wifi and ethernet between the passengers and maybe a quake server would be an excellent thing on a plane.
External comms is nice, but a LAN party on a plane is awesome.
This is why you make a tinfoil hat: to keep the radio waves out of your head. It's simple to do, and as a bonus the voices stop.
Most people screw up and make an aluminium foil hat.
What is your motivation for saying these things?
Distrust of an untustworthy government, I'd imagine.
How about you prove him wrong, if you feel so strongly about Intel's virtue?
Proof is for mathematicians. Oh look, here's one: https://eprint.iacr.org/2014/5...
You are missing the point.
AC made an assertion he knows that he or she doesn't know. It was a lie.
I know it to be a lie because I know the circuit. Several other people on this planet know enough to know it is a lie.
Other people don't know, which is just how the universe works.
If you are interested in testing random numbers, you are welcome to buy my book on the subject when I finish writing it in about 20 years.
I'd like to see clear(er) written guidelines for how say customer data should be cared for. And because their may be valid reasons to deviate from the guidelines, perhaps request that the reason for the deviations be written down by the organization and supplied on request to the FTC.
Oh, you mean like when a company agrees to process credit card transactions the written guidelines that dictate PCI-DSS 3.0 compliance?
(Sorry, but in the example provided in TFS, it sure as shit seems pretty cut and dry)
Can you explain how PCI-DSS 3.0 stops anything getting hacked? You know the Target and Home Depot systems were PCI compliant right?
The NIST stuff isn't so awful, but it's not in a form that's very useful. It's lots of little specs that don't fit together into a system. However it contains very useful specs on means for an organization to protect itself. This is good.
This is a solvable problem, but the PCI specs are a barrier to uniform adoption of something effective.
>Oh and did I mention the random generator is biased?
Would you like to substantiate that with evidence?
I know you can't. You know you can't.
What is your motivation for saying these things?
>better performing for less
Enterprise-class hardware? Maybe if you're overpaying for it.
If you owned the same hardware that amazon does, it would be cheaper and faster than running it on amazon's VMs. Faster for the obvious reason that you're running on bare metal and not inside a VM, and cheaper because Amazon wouldn't profit if their income from renting VMs was less than what they spent on hardware. Check the price of renting a big VM for 3 years versus buying the equivalent real hardware.
None of this is to suggest that there aren't other benefits to using VMs. Like you said, resilience and monitoring. Someone else's grunts are dealing with the hardware instead of you.
If you do it right, you should be able to guarantee some base load that will keep some computers busy. Buy those and run the system on it. Then use the cloudy servers to scale up as variable load happens. The cloud stuff isn't cheaper unless you are avoiding paying for idle hardware.
The Kazakhstan problem goes like this..
You can't tell where your cloud computing is hosted. Any host can delegate to some other host.
So Vendor A with well paid shiny sales people sells cloud hosting.
Vendor A outsources the physical part of the cloud to Vendor B who is a bit cheaper with slightly less well paid sales people. Vendor A cashes the difference.
Vendor B outsources to vendor C in China who is cheaper still. Vendor B cashes the difference.
C -> D
D -> E
Repeat a few times until all the world's cloud computing it running on a server in a cupboard in Kazakhstan.
If the online payment service appears to the end customer to be on your website, then a malicious hacker could replace your website with a version which harvests credit cards. I realize that PayPal (and possibly Stripe) successfully lobbied for their embedded form service to be excluded from the more rigorous PCI auditing category (forgive the ambiguity, it's been awhile since I dealt with PCI compliance), but that's politics, not security. I wouldn't count on it lasting, either.
Nevertheless, it's the right thing to do from a practical standpoint. The higher audit levels would require every mom and pop website software to be audited. Encapsulating in a window served from their servers is the right way to shield customers from the mess that is random website design and actually get it out there. If you had the higher audit levels, it wouldn't get used at all and we would have people typing thier card data into nasty php scripts written by a friend of the proprietor's daughter.
There is little in the PCI specs that adds to the security of card transactions. These are the same people who've held back the adoption of EMV for a decade and the specs focus on vendor 'process' more than things that matter, like defense in depth system design. We have a shiny new EMV and NFC compatible card reader and it has a big sticker on the bottom proclaiming it to use triple DES, like that's a good thing. Look a bit deeper and it's 1024 RSA for the key agreement and some mode of DES for the transactions. The 1990s called and wants its crypto back. This is written in some software on a microprocessor in the box. I have no way of knowing how crappy that software is, except my years of experience in secure system design that tells me it'll have more holes than Swiss cheese. But it would violate PCI-DSS rules for me to open the box and take a look inside.
Right. I did a little research that suggested the payment processor wasn't incompetent when it came to security. However the average yarn store owner wouldn't know how to do that.
She can tell bad yarn a mile off though. We already dropped a couple of suppliers who moved their manufacturing to China and the quality dropped. However don't take that to mean all yarn that's been through China is bad. Chinese yarn processors apply the superwash process to some quality yarns.
The card processor is not supposed to hang onto card data, but we have no way of really knowing. There are limits to what you can achieve because you are forced to rely on a number of external organizations (banks, networks, payment card processors, equipment vendors etc.) that you have not much choice in.
If PCI-DSS specs were well architected and written, payment card equipment would be more secure and enable integration with point of sale systems without passing sensitive information through the PoS, thus reducing the attack surface.
If the business grows large enough, we would hire some serious security experts and developers to develop our own secure payment processing. But the business couldn't support it right now and I get paid much more by working as a security expert for a large semiconductor corporation.
You have a choice, you (the payment card industry) self-regulate, or the government steps in and tells you how to do it.
If you don't like the PCI-DSS, try to imagine what government's version would be.
Imagine if they farmed the spec writing out to a list of likely suspect techy companies who have shown themselves able to create secure specs. They couldn't do worst than PCI-DSS or the government.
But in this case it's not the credit card information that anybody cares about -- it's the customer data.
Imagine that you could tell somebody's deepest-darkest secrets based on what kinds of yarns they looked at! You'd now have to protect the core of your business data (that's a lot harder to meaningfully encrypt when you have to spend most of your time actually processing that data).
dom
Yup. If you're planning to process sensitive customer data, it's not enough to expect an IT department to do it. You need to make procedural and cryptographic security the core of your business and put practitioners of those disciplines in senior positions in the company.
If not, you and your customers are just lambs to the slaughter.
We don't attach people's names to transactions unless they ask for it. So the yarn-dark-secrets link is relatively safe from the 2000 or so hacking attempts that get made on our little server every day.
I think I could make a secure system for handling customer data, but it would be a full time job and I already have a job.
Anyone trying to use this extremely common words combination will have to pay royalties?
You seriously have absolutely no idea how trademarks work?
I do have a bit of a clue. I have a couple of trademarks.
I am surprised that a watch vendor got a trademark on a phrase used in promotional performances by another watch vendor. Maybe lawyers will be sharpening their quills.