I've driven over 800 miles across six months on a tire that was completely flat, on the front wheels of a front wheel drive car, and then put air in it and driven off. It wasn't a run-flat, and wasn't inflated between. It was a Dunlop Signature Sport stock dealer tire (never buy these! They suck!).
I drove from Baltimore to DC and back with a rear tire flat the whole time (a Goodyear Assurance TripleTred, something actually useful), and then put air in it when I noticed it was flat. That's like 300 miles in one day.
I had a tire explode on me once. It wasn't low, and hadn't been thusly abused; it had about 12,000 miles on it. I didn't realize it had exploded; I felt the car start to go thump-thump-thump and knew one of the tires probably had gone flat or something, so pulled off the expressway and found four pieces of tire loosely held together by some sort of nylon mesh wrapped round my wheel. Apparently my car doesn't go spinning out of control when the front passenger tire explodes at 80mph, either. I fucking love this car.
As far as I can tell, tires just blow up when they feel like it. Ridiculous abuse hasn't failed my tires, but normal driving with 35-40psi in a 50psi rated tire has.
You can make a lot of money building up bitcoins. It may take a year to get your investment back, and then 3 years to get major profitability. You're going to essentially be rich as fuck in 10 years' time.
In 2 months, the bitcoin market might crash. This bubble has to pop some time. By cashing out the marginal value of your bitcoin mining rig now, you reap immediate guaranteed profits and transfer the risk of loss to the customer.
Still wrong. VASIMR ejects ionized particles--mass--which is the same problem as a chemical rocket: eventually you run out of shit to eject.
We're looking for a technology that can take energy and turn it into movement without ejecting any mass. In other words: We're looking to keep going even when we have no mass to eject. You can't eject the control units, the ship's body, its atmosphere, or its crew, if you want it to keep functioning or support life; so your nuclear pile might remain hot longer than your mass resources hold out.
Also, competition stabilizes the market by allowing your competitors to market the need (i.e. the Tesla is a novelty at best, not a serious product; when Chevrolet and Honda stop dicking around with their novelty cars and start telling us all how much we need electric cars, the Tesla suddenly becomes a serious product).
Yes, but that's what a separate database zone is: you make your/24 subnet break down into/28, you VLAN it, break down the firewall rules, and have groups of 14 nodes. Databases (3 x MongoDB, 3 x PostgreSQL), application servers (might be one server, or might be 3 subnets), HTTP servers, your SSL concentrators, etc.
Your DMZ is going to be an isolate bubble: even the production LAN can't get into it, except for services offered. So even if you have one DMZ on a/24 that's got HTTP, database, SSL concentrators, and so on, your situation isn't as bad as you suggest. VPN? Either the VPN has SSH access to all your databases (i.e. your on-database-server firewall allows SSH from internal, and the VPN isn't trapped in a firewall that blocks SSH) or it doesn't. Either it has database access or it doesn't.
I really did mean "Trust Zones". DMZ is a trust zone, and you are trusting it to interact with your Private LAN trust zone in a specific way. No matter where you put the firewalls, it interacts the same way. Firewalls on that host in particular aren't necessarily useful: why is it exposing Console Character Service or CUPS Print Service if it's not supplying print services to its own subnet? Configure that shit off, or bound to 127.0.0.1 or a local socket. If it's supplying those services to the subnet it's on, then your border firewall shouldn't allow those services through to that subnet--from private LAN, from Internet, or anywhere else.
The old idea of "The Internet" versus "The Private LAN" is obsolete. We group things on subnets and put firewalls between the subnets now.
Might be. We're 2000 years off from Christ, and the Greeks were what? 1000 or 2000 BC? Galileo was around 1400s or 1600s? I don't remember.
It's still within Fermi estimation and thus still valid: how the fuck do you go thousands of years without checking that a brick falls faster than a grape?
If your database is in a trusted network zone, it's fine.
If you have a bunch of assets outside the corporate firewall, you're doing it wrong. These belong behind a DMZ firewall, blocking any ports not strictly necessary, possibly with PNAT and coalescence (i.e. an FTP, Web, and Mail server, natted to the same address, ports 80, 443, 25, 21, and FTP PASV going to different addresses behind that).
Within that DMZ, servers provide whatever services they're going to. MySQL on port 3306 will provide MySQL on port 3306; if you add a local firewall, you will have a firewall that blocks all non-listening ports and leaves port 3306 open, so no difference. If you're worried about ssh, use an IP console card (DRAC, etc.) on a separate subnet, or put the database servers behind another firewall. It is, in fact, common to create trust zones for front-end, application, and database, such that i.e. your Web servers connect through WSGI to a CherryPy application, which connects back to a Database, through a firewall in each step. You can do this with vlans and broken-down subnets, one switch, and one firewall.
You have to consider everything when you design secure network architecture.
Every time somebody says something, it passes through the public mind. Sometimes it gets down five people and dies; others, it becomes an ever-growing ball of horse shit, and people start claiming that it takes 8 pounds of honey to build a honey comb that holds 1 pound of honey when, in reality, beeswax is pretty cheap in terms of hive storage economy.
There are so many untrue things on Wikipedia just by way of almost everyone believing them--things that are printed in earnest in College textbooks and technical manuals, repeated by experts in field, and yet readily testable as not-true. These are just like Aristotle claiming heavier objects fall faster--and, 3000 years later, Galileo drops a grape and an iron brick at the same time, and both hit the ground simultaneously; did nobody think to check something other than a rock versus a feather? Today, we have the same.
To make matters worse, anyone can purchase a domain name, set up a Web host or lease hosting, and publish anything they want with nobody able to edit it or mark it as suspect or inaccurate. Between word-of-mouth, books printed by whoever the hell wants to, Web sites with no validating authority, and forums where inaccurate posts aren't edited by moderators or community and are often supported by a circle jerk of clueless idiots, where do you expect to get any authoritative information?
Wikipedia has the public access problem in a different scale: anyone can post anything on the Internet or in books or private magazines without contradiction; but, on Wikipedia, you get only as much contradiction as attention, amplified inverse to plausibility. That is to say: if what you post is not obviously wrong and not on a high-traffic article, it will probably fall through; if what you post is ridiculous or is on a high-traffic article, someone will notice the inaccuracy.
It's just that saying C++ is more complex than Java has little bearing on C. C++ is an immensely complex language: loading and using C++ programs is slow. The overhead of using C++ is immense. It's incredible. Name mangling causes tons of comparisons in initialization and during lazy look-up; while classes require constant indirect look-ups through the virtual method table as a matter of course.
In C, you have none of that. memcpy() is just memcpy(), and it's in the PLT. A call to memcpy() doesn't invoke a look-up through the virtual method table to determine which pointer to use for a call %register,$pointer; it's just stuffed into the PLT, and a call to it causes a hard-coded call %register,$offset.
There are no template functions in C because of no name mangling.
In Project Management, procurement management involves advertising and bidding contracts, selecting sellers, writing up the statement of work, quality guidelines, etc., then continuing with performance reviews and metrics to track the quality of work and determine if it meets the contract and the project needs.
Well, the statement was made 2 days ago, so "last year" doesn't count. Until last year, your girlfriend was single, so having sex with her last night was okay, right?
That argument is stronger. Your argument was, "If it wasn't there at the start...." which is irrelevant when speaking about proportion.
You substituted "100%" for "majority", which need only mean "50% plus some". Linux was released 23 years ago; ICC version 6 was released in 2002, 12 years ago. That's 11 years before ICC version 6.0 for Linux and 12 years with it; I don't have numbers for pre-6.0, but assume earlier releases came at chronologically earlier points in time. Given its rapid development in that period, the earliest likely release was 2000 or so; but 2002 is the earliest release I have data for.
There have been no other credible compilers for Linux throughout the majority of its existence
Except the Intel C compiler, which is inappropriate for other reasons stated (i.e. it's shitty for non-Intel architectures). Still, given the argument--a GCC bug on x86/x86-64--and the twelve years of potential tuning for icc to support high-performance situations (i.e. embedded architecture, where 16% speed-up matters), broad compiler support is reasonable. It's not like LLVM just becoming useful last year and triggering a scramble to rebase onto CLANG.
2002 was the year of Gnome 2.0, of Linux entering the 2.5 development cycle (2.4 was state-of-the-art), of SuSE 8.0, of single-core CPUs and no AMD64. It was a long time ago, a different age, when journaling file systems were hip and new and Hans Reiser hadn't murdered Nina yet.
"Throughout the majority of its existence." The term "majority" has a meaning. If you continue to argue in such an asinine way, I will have to add you to the WOR extension rated as a double-plus Retard for deceptive malformation of the English language in debate.
Slashdot Mirror
I've driven over 800 miles across six months on a tire that was completely flat, on the front wheels of a front wheel drive car, and then put air in it and driven off. It wasn't a run-flat, and wasn't inflated between. It was a Dunlop Signature Sport stock dealer tire (never buy these! They suck!).
I drove from Baltimore to DC and back with a rear tire flat the whole time (a Goodyear Assurance TripleTred, something actually useful), and then put air in it when I noticed it was flat. That's like 300 miles in one day.
I had a tire explode on me once. It wasn't low, and hadn't been thusly abused; it had about 12,000 miles on it. I didn't realize it had exploded; I felt the car start to go thump-thump-thump and knew one of the tires probably had gone flat or something, so pulled off the expressway and found four pieces of tire loosely held together by some sort of nylon mesh wrapped round my wheel. Apparently my car doesn't go spinning out of control when the front passenger tire explodes at 80mph, either. I fucking love this car.
As far as I can tell, tires just blow up when they feel like it. Ridiculous abuse hasn't failed my tires, but normal driving with 35-40psi in a 50psi rated tire has.
Risk.
You can make a lot of money building up bitcoins. It may take a year to get your investment back, and then 3 years to get major profitability. You're going to essentially be rich as fuck in 10 years' time.
In 2 months, the bitcoin market might crash. This bubble has to pop some time. By cashing out the marginal value of your bitcoin mining rig now, you reap immediate guaranteed profits and transfer the risk of loss to the customer.
They did that in AU. It didn't help.
No, those are DC-8s with rocket engines.
Still wrong. VASIMR ejects ionized particles--mass--which is the same problem as a chemical rocket: eventually you run out of shit to eject.
We're looking for a technology that can take energy and turn it into movement without ejecting any mass. In other words: We're looking to keep going even when we have no mass to eject. You can't eject the control units, the ship's body, its atmosphere, or its crew, if you want it to keep functioning or support life; so your nuclear pile might remain hot longer than your mass resources hold out.
Imagine a nuclear 747. The turbines spin, air moves through, and the plane moves. Great for a 50 pound brick of metal as a fuel source, eh?
Now imagine that 747 in space.
One of these things actually works. The other doesn't.
Also, competition stabilizes the market by allowing your competitors to market the need (i.e. the Tesla is a novelty at best, not a serious product; when Chevrolet and Honda stop dicking around with their novelty cars and start telling us all how much we need electric cars, the Tesla suddenly becomes a serious product).
Get out of here with your opinions.
Perhaps you have not met The French?
Yes, but that's what a separate database zone is: you make your /24 subnet break down into /28, you VLAN it, break down the firewall rules, and have groups of 14 nodes. Databases (3 x MongoDB, 3 x PostgreSQL), application servers (might be one server, or might be 3 subnets), HTTP servers, your SSL concentrators, etc.
Your DMZ is going to be an isolate bubble: even the production LAN can't get into it, except for services offered. So even if you have one DMZ on a /24 that's got HTTP, database, SSL concentrators, and so on, your situation isn't as bad as you suggest. VPN? Either the VPN has SSH access to all your databases (i.e. your on-database-server firewall allows SSH from internal, and the VPN isn't trapped in a firewall that blocks SSH) or it doesn't. Either it has database access or it doesn't.
I really did mean "Trust Zones". DMZ is a trust zone, and you are trusting it to interact with your Private LAN trust zone in a specific way. No matter where you put the firewalls, it interacts the same way. Firewalls on that host in particular aren't necessarily useful: why is it exposing Console Character Service or CUPS Print Service if it's not supplying print services to its own subnet? Configure that shit off, or bound to 127.0.0.1 or a local socket. If it's supplying those services to the subnet it's on, then your border firewall shouldn't allow those services through to that subnet--from private LAN, from Internet, or anywhere else.
The old idea of "The Internet" versus "The Private LAN" is obsolete. We group things on subnets and put firewalls between the subnets now.
Might be. We're 2000 years off from Christ, and the Greeks were what? 1000 or 2000 BC? Galileo was around 1400s or 1600s? I don't remember.
It's still within Fermi estimation and thus still valid: how the fuck do you go thousands of years without checking that a brick falls faster than a grape?
If your database is in a trusted network zone, it's fine.
If you have a bunch of assets outside the corporate firewall, you're doing it wrong. These belong behind a DMZ firewall, blocking any ports not strictly necessary, possibly with PNAT and coalescence (i.e. an FTP, Web, and Mail server, natted to the same address, ports 80, 443, 25, 21, and FTP PASV going to different addresses behind that).
Within that DMZ, servers provide whatever services they're going to. MySQL on port 3306 will provide MySQL on port 3306; if you add a local firewall, you will have a firewall that blocks all non-listening ports and leaves port 3306 open, so no difference. If you're worried about ssh, use an IP console card (DRAC, etc.) on a separate subnet, or put the database servers behind another firewall. It is, in fact, common to create trust zones for front-end, application, and database, such that i.e. your Web servers connect through WSGI to a CherryPy application, which connects back to a Database, through a firewall in each step. You can do this with vlans and broken-down subnets, one switch, and one firewall.
You have to consider everything when you design secure network architecture.
Take a look at Snopes once, huh?
Every time somebody says something, it passes through the public mind. Sometimes it gets down five people and dies; others, it becomes an ever-growing ball of horse shit, and people start claiming that it takes 8 pounds of honey to build a honey comb that holds 1 pound of honey when, in reality, beeswax is pretty cheap in terms of hive storage economy.
There are so many untrue things on Wikipedia just by way of almost everyone believing them--things that are printed in earnest in College textbooks and technical manuals, repeated by experts in field, and yet readily testable as not-true. These are just like Aristotle claiming heavier objects fall faster--and, 3000 years later, Galileo drops a grape and an iron brick at the same time, and both hit the ground simultaneously; did nobody think to check something other than a rock versus a feather? Today, we have the same.
To make matters worse, anyone can purchase a domain name, set up a Web host or lease hosting, and publish anything they want with nobody able to edit it or mark it as suspect or inaccurate. Between word-of-mouth, books printed by whoever the hell wants to, Web sites with no validating authority, and forums where inaccurate posts aren't edited by moderators or community and are often supported by a circle jerk of clueless idiots, where do you expect to get any authoritative information?
Wikipedia has the public access problem in a different scale: anyone can post anything on the Internet or in books or private magazines without contradiction; but, on Wikipedia, you get only as much contradiction as attention, amplified inverse to plausibility. That is to say: if what you post is not obviously wrong and not on a high-traffic article, it will probably fall through; if what you post is ridiculous or is on a high-traffic article, someone will notice the inaccuracy.
It's just that saying C++ is more complex than Java has little bearing on C. C++ is an immensely complex language: loading and using C++ programs is slow. The overhead of using C++ is immense. It's incredible. Name mangling causes tons of comparisons in initialization and during lazy look-up; while classes require constant indirect look-ups through the virtual method table as a matter of course.
In C, you have none of that. memcpy() is just memcpy(), and it's in the PLT. A call to memcpy() doesn't invoke a look-up through the virtual method table to determine which pointer to use for a call %register,$pointer; it's just stuffed into the PLT, and a call to it causes a hard-coded call %register,$offset.
There are no template functions in C because of no name mangling.
Using some magic Ajax, you could pull the ad and see what's on it. If it's a Police ad, replace it with something different.
Saag is better than Korma.
In Project Management, procurement management involves advertising and bidding contracts, selecting sellers, writing up the statement of work, quality guidelines, etc., then continuing with performance reviews and metrics to track the quality of work and determine if it meets the contract and the project needs.
Obviously, that didn't happen.
"Better" is not a purely subjective term. Something with higher quality and lower cost is objectively better.
Well, the statement was made 2 days ago, so "last year" doesn't count. Until last year, your girlfriend was single, so having sex with her last night was okay, right?
DB/2? What about PostgreSQL?
That argument is stronger. Your argument was, "If it wasn't there at the start...." which is irrelevant when speaking about proportion.
You substituted "100%" for "majority", which need only mean "50% plus some". Linux was released 23 years ago; ICC version 6 was released in 2002, 12 years ago. That's 11 years before ICC version 6.0 for Linux and 12 years with it; I don't have numbers for pre-6.0, but assume earlier releases came at chronologically earlier points in time. Given its rapid development in that period, the earliest likely release was 2000 or so; but 2002 is the earliest release I have data for.
There have been no other credible compilers for Linux throughout the majority of its existence
Except the Intel C compiler, which is inappropriate for other reasons stated (i.e. it's shitty for non-Intel architectures). Still, given the argument--a GCC bug on x86/x86-64--and the twelve years of potential tuning for icc to support high-performance situations (i.e. embedded architecture, where 16% speed-up matters), broad compiler support is reasonable. It's not like LLVM just becoming useful last year and triggering a scramble to rebase onto CLANG.
2002 was the year of Gnome 2.0, of Linux entering the 2.5 development cycle (2.4 was state-of-the-art), of SuSE 8.0, of single-core CPUs and no AMD64. It was a long time ago, a different age, when journaling file systems were hip and new and Hans Reiser hadn't murdered Nina yet.
Linux isn't in C++
"Throughout the majority of its existence." The term "majority" has a meaning. If you continue to argue in such an asinine way, I will have to add you to the WOR extension rated as a double-plus Retard for deceptive malformation of the English language in debate.
You see my point, though. Knowing your administrator log-ins isn't a never-happens situation. People get user lists all the time.
The arrangement of matter is information.