Of course, you might have a good ability to challenge a ticket on it by looking to see if the sign change itself was legal (e.g. authorized) or if someone just switched it trying to get more people to stop and leave the intersection clear that they already should have been doing.
That right there addresses the crux of my point. To tell if something is illegal or not, the clear markings on the road and the laws as written don't necessarily apply.
Actually, even if the sign was switched illegally, you're still bound by law to obey it as it still qualifies as a "posted signed". You're also bound to obey the written lawss as they are on the books.
However, that doesn't mean that in that situation if you find that it was illegally posted, that you can't get it challenge it on that ground - and if you find out who illegally posted it, they'll could get fined or jail time too. It's not a matter of ambiguity.
It also doesn't mean that an officer won't use their discression in how they apply the written laws. For example, in Pennsylvania the written laws is that you are speeding and the officers are to ticket you even if you are 1 MPH over the speed limit - which is obviously impractical, and while officers can ticket you that way, they don't usually - the usually wait for it to be 5 or 10 MPH over. But that doesn't mean they couldn't do it by the book and follow the written law 100% - they very well could, and you can't do a thing about it if you didn't follow it that way.
Or, at lease, the laws include the federal laws, the state laws, the town/county/parish laws, the minutes of whatever local body decided to put up the sign, the actual actions of whoever put up the sign, and all related case law. Even then you have no way of knowing how an eventual court case might turn out.
Doesn't matter. You're still bound by them all; with each level overriding those below it. That is, if a federal law says to do X and a state writes a conflicting law to do Y, then you're still bound to do X. Same between between Federal and local, and State and local. The lower levels of government can only refine what the upper levels legislate - not contradict it. It gets a little messy between State and Federal only because of the limited ability of the Federal government to regulate States, which has been drastically (and illegally) expanded over the last 50 years or so.
Essentially, if they put thirty-three stop lines on the same light, spaced 30 meters apart, and the town council approved it, the same traffic light would legally cover all those intersections over an entire kilometer (and it's on a long downhill grade, you can see the light about a kilometer away).
Yes. And unless there was something in the laws above them saying they can't do that then it'd be perfectly legal and you have to follow it.
The problem is, you're making an argument from common sense. You are not, I assume, a lawyer. For example, you say that of course you can take a right on red at any of those stop lines, but what are you basing that on? Aside from me mentioning that right turns on red at stop signs are legal in my state, what do you actually know about the laws in my state?
Correct, I am not a lawyer. However, in most states it is legal to make a right turn on red unless otherwise posted. Same for U-turns. One thing the federal government and states has done is make the driving laws as uniform as possible.
The law might be phrased in such a way that it describes an intersection where you can take a right turn on red and a second stop line for the same red light doesn't fit that description, but at the same time, the law doesn't say you can't have multiple stop lines for the same light. If that's the case, then it's a valid legal interpretation that you can only take a right turn on red at the first stop line, but it's also a valid in
While I agree with your main point about the ambiguity of the law and such...
Near my house, there's a T junction about 20 meters from a red light. At the intersection, there's a stop line. They used to have a "do not block intersection" sign back at the T junction so that traffic could still turn down the side street. They've replaced it with a "stop here on red" sign. The intent seems to be to create two stop lines for the same red light. The actual law is largely ambiguous on this. It definitely doesn't address this particular situation, but it doesn't say that the town, _can't_ do it. Most people just completely ignore the sign. I just do what I always did before and I don't block the intersection when there's a red light. No-one seems to be able to tell if they're actually required to stop there and, if they do stop, if they have to stop like they'd stop at a red light, or it they have to stop like they'd stop at a stop sign, also, since the turn there is a right turn, and a right turn on red is allowed at a stop light in my state, is a right turn on red allowed there since it's not actually at the light?
You have to treat it just the same as the line at the stop light. If the light is red, then you have to stop there; if you can turn right on red, then by means do so. There is no ambiguity in there other than what you want to add. Yes, people may not pay enough attention to it since it is further from the light than it should be, but it is still nonetheless part of the intersection.
Of course, you might have a good ability to challenge a ticket on it by looking to see if the sign change itself was legal (e.g. authorized) or if someone just switched it trying to get more people to stop and leave the intersection clear that they already should have been doing.
There's a similar intersection where I live. The light sits just across the rail road tracks, on both sides of which are a road, and then another main road crosses all three. The one road only has stop signs. Yes, there is a "stop here on red" in two places for the road that crosses the tracks - one right before the tracks, and one before the side road with the stop signs. Don't dare treat the first "stop here on red" like a stop sign - they will ticket you.
Consider a left turn at a light where there isn't a separate left turn signal. If the traffic coming in the other direction is continuous, they have the right of way and you can't turn left unless you move to the middle of the intersection, wait for the light to change, then turn. This is illegal. It's what everyone does in that situation and, 9 times out of 10, a police officer watching you do this won't even care.
That is NOT illegal. Its ill-advised by driver's ed; but it is NOT illegal. That is why the officer doesn't care.
where the intersection actually ends and you're no longer bound by the light is poorly defined both in law and in physical reality. Most people consider themselves clear when they can no longer see the light, but obviously that's at a different point depending on where the light is mounted.
There is no ambuity there. It has nothing to do with whether you see the light, and everything to do with whether or not you are blocking traffic from any direction - e.g. the cars to your left and right. If you haven't crossed the "stop here on red" line for the direction you're going, then you are still in the intersection, and thereby officially blocking it - even if no other cars have yet entered. Again, you're putting ambuity in there because it suits you, not because it is actually there.
More like: Pot, Kettle, Cauldron; meet Stainless Steel Soup Pot. Stainless Steel Soup Pot, meet Pot, Kettle, and Cauldron.
Well, yeah - that Stainless Steel Soup Pot may be well used and have a bit of black on it too; but nothing like the Pot, Kettle, and Cauldron which were black even when brand new.
I'm sure the first step is to pump off as much fuel oil as possible.
I'm guessing it's not 120m tall. Even if it settled upright. Perhaps an Antenna will be left above water.
120m is roughtly 360 feet. According to Wikipedia it has 17 decks; figuring on that a deck is about 10 feet apart, that's 170 feet there, but there will also be space between the decks (which will probably be 3-5 feet) and some decks (especially the upper most and lowermost decks) will have a lot more space, not to mention the various engineering rooms in the lowermost sections, and double-hulls, etc. So it can easily be more than 360 feet tall.
Lets hope that whatever follows has the same longevity as VGA. In a world where we've invented USB 3 times (USB, mini USB and micro USB) with non-compatible connectors in just 11 years, the future does not look as good.
Wasn't re-invented; just added to in order to support multiple form factors. You don't find mini or micro USBs on desktop/laptop/server computers. You also don't find USB on phones or tablets, or other small form-factor devices.
While I like DVI and have a monitor that uses it, going HDMI only is not a big deal. HDMI is just DVI plus a little extra, for audio, and the cost of that "little extra" is already negligible.
This means that a DVI-DVI, HDMI-HDMI, and DVI-HDMI cable are the same price. I spent $5 on one a few years back.
No difference! Unbunch your panties
Except HDMI also interfaces with HCMI which is what content companies (RIAA, MPAA) really want you to have so that they can "close the analog hole". HDMI will also talk with HCMI devices, but announce that it is not HCMI and therefore block the content from the HCMI port. This is their ultimate goal. DVI was just a way to start towards that, and VGA was their enemy.
Right the ship, drain the fuel and leave it there. You only have to stop it from sinking, you don't need to make it seaworthy.
Correct - it doesn't have to be seaworthy - it just has to make it into a floating dry-dock (which is seaworthy) so that they can transport it to a proper place for repair or salvage.
It's on an underwater mountainside hung up on a rock protrusion. The bow and stern are slumping, but the center is maintaining height. It's back is likely broken.
Still, it supposedly only has another 120m to go to the next shelf bottom; so sinking it where it is doesn't necessarily make sense either - I'm pretty sure it's a lot taller than the water is deep there. But you may have a good point for not being able to salvage it. OTOH, they may be able to get it to a floating dry-dock to safely move it away - which would be easier than trying to float it all the way to an actual dry-dock - you'd only have to float it for a few days at most while you get it into the floating dry-dock.
Oh really? You've shifted to an argument that ignorance will drive the choice? Why did you even consider it worth typing that it? Do you really think it's going to be taken seriously?
It has nothing to do with ignorance and everything to do with what is available for managing networks with IPv6 installed. The fact is, there is a lot less support for doing things businesses deem critical for network management in IPv6 than there is for IPv4. Part of that is just the age and maturity of IPv6 and the various tools out there; but part of it is also by design.
For example, by design IPv6 was not suppose to have DHCP ever - it was suppose to be built into the network by the local system providing its MAC address or another number as the lower bits and then auto-detecting the upper bits (Link Local). As a result, they ignored DHCP for a long time - it's only come about in the last couple years.
Again, by design you were not suppose to ever using NAT'ing or other means of segregating networks or hiding a network (however large) behind a single IP (the purpose of NAT). They wanted everything on the public network. However, this means large security concerns as you now have a whole host of additional devices, etc. that would be on the network. Add to this the fact that at least early IPv6 (well, if you could 2009 still as being early IPv6) was known for getting out of firewalled networks - and yes, IPv6 firewalls were available (at least on Linux) at that point.
So there is no ignorance involved. It is a matter of various security concerns that primarily businesses (and gov't) have with controlling who is on their network, and who has access to what, and how the architecture of the network. The IPv6 backers have largely ignored much of that, or designed methods that are inadequate to address the real concerns - even by design removing functionality entirely that was desired and necesary. Now the "design" is getting hacked up to add those features as IPv6 won't be able to go forward without them - the recent advent of DHCPv6 being one example.
IPv4 was generally really simple; and you built tools to manage it. With IPv6 they tried too hard to build those things into IPv6 itself; thereby making it too complex. They should really have gone with a similar approach for IPv6 as they did for IPv4 - just keep IPv6 to addressing and let other standards, other tools do the rest.
It has already been well shown that IPv6 will enable even computers on private networks to escape the firewalls in place, completely bypassing the security restrictions.
Only if the firewall is incapable of dealing with IPv6.
I'm sorry, but I don't see your argument of "X is rubbish if not fully implemented so let's not use X at all" as valid.
Elements of it are going to be crap without hardware or software that supports it properly, but eventually it's going to be usable in more and more situations.
You're missing the point - that's how network adminstrators and (more importantly) their bosses are going to look at it that way and make the decision that way.
I certainly have full control over my firewall and what it supports (since it's a Linux-based server running Gentoo); so it's not as big an issue there from the firewall side; however, having the ability to control the network addressing is - I want my network to be private and fully controlled; no traffic gets in or out unless I say so. And that is (to an even greater extreme) how many large enterprises run their networks - so that would be a very valid issue for them; while it might not be for you.
That doesn't mean not testing it or working with it; but it will prevent mass migrations and support by from big companies.
Or everyone will run their systems via a single machine that does firewalling, has a single address, blocks access to internal networks ... IPv6 deployments won't see any more publicly-routed traffic than previously.
Unfortunately, IPv6 will break a lot of firewalls and security etc. It has already been well shown that IPv6 will enable even computers on private networks to escape the firewalls in place, completely bypassing the security restrictions.
The issue is that IPv6 makes it really easy to have everything on the public network, and really hard to change that.
I had considered changing my home network over to IPv6 only, and then run a 6-to-4 gateway on my server. However, I quickly found out that controlling the network addresses was a HUGE problem. With IPv4, I assign each system its own static IPv4 address based on its MAC address; and the IPv4 address is tied to the internal DNS. I can do it completely transparently. Similar stuff for IPv6 is still in its infancy, with the pro-IPv6 people for a long time completely ignoring DHCP. (Yes, DHCPv6 is now available, but no where near as complete and functional as DHCP for IPv4.)
So a lot of the resistence to IPv6 has probably been due to the pro-IPv6 people's hatred for a lof the security, network management, etc. that people have come to love under IPv4. I will certainly run a 4-to-6 gateway for my internal network before giving up that kind of control, and I suspect many large organizations and their network nazi's will too.
Summary: IPv6 is its own worse enemy; but it's getting better. Just don't expect it to be your friend any time soon.
Everything is a gender or race issue. Why is this so important?
It's a result of the Civil Rights and Femmenists movements. Everything has to be as equal as possible or the ACLU, NAACP, NPR, and femmenist groups raise hell.
She's not even two yet and I hate pink. Like I said, she stays home with her dad who likes to dress her up like a dinosaur. Where the fuck did she pick up the stereotype that she should prefer the pink shirt to the blue shirt?
Well, to answer the GP's question - probably from all the pink baby gear she got at her baby showers, etc. There's just so much of it you can't help it. I've got a 11 month old son, and it's hard to find stuff for boys as something like 75% of the baby stuff is for girls. It's frustrating at times.
I suspect that liking pink is innate to boys and girls alike. I have seen little boys (less than 3yo) go for bright pink objects over any other color. I am led to assume that pink just feels like a vivid, yet soft and pleasant color to us - that is, before we males duly acquire proper male tastes, and grow a strong, healthy distaste for it.
Well, while it may have that its more a social thing for why boys tend to shun pink than anything else. Boy's tend to hate being called "girlie", etc by their peers, which is probably what drives it. So they'll probably be okay wearing pink or whatever until they get to preschool or even early elementary when those kinds of peer things really take off and they become social and want to be accepted; then they'll start shunning things just because they think it'll make them fit in better. Of course, you'll get the occassional kid that won't care and will go about things any way they please; but they're the exception not the rule - though if they are the most popular then it may dampen the effects on the others.
And they specifically used the same FS number as HPFS which Microsoft and IBM jointly developed for OS/2 [...]
The reason for that should be pretty obvious - NTFS was supposed to replace HPFS in what was then still called OS/2 NT.
NTFS development started along with NT development in the late '80s. Back when IBM and Microsoft were still BFFs and *years* before they would have any thoughts about "compatibility".
NTFS was NOT jointly developed by Microsoft and IBM, HPFS was. Microsoft did NTFS as part of Windows NT after the split. And FYI - Windows has never really recognized the HPFS or HPFS+ file systems - both used by OS/2 and Mac OS, and instead calling them "corrupted" NTFS file sytems. Yes there are a lot of shared features between the two; but that probably has more to do with the fact that Microsoft worked on HPFS than anything else - they probably saw them as good features to have as a result, and thereby incorporated them. (Not to mention the marketing perspective.)
I'll also point out that Wikipedia disagrees with you as well (see NTFS Wiki article - just read the page source for blackout day) as to the origin of NTFS; while it does kind of agree in the assumption of why NTFS uses the same disk type as HPFS but for different reasons.
And they specifically used the same FS number as HPFS which Microsoft and IBM jointly developed for OS/2, and was also used by Apple for MacOS specifically to keep systems from being compatible.
So, watch them use partition table FS identifier 82 (Linux FS - Ext2/3/4) instead...for the same reason. However, that has typically only hurt Microsoft as everyone else figures out how to be detect the differents FS's on the actual partition, especially the Linux folks.
Are they actually going to release this one? I remember one of the big features of Vista was to be their new filesystem Win FS. Although, I guess Microsoft had enough criticisms to deal with in Vista that it could have been even more of a disaster to release a new filesystem with it.
WinFS was ditched before Vista development was started. Yes, it was part of the original Longhorn project; but that project after 3 years was tossed, and a new Longhorn project was started that became Vista, and then reved and became Win7; but if I recall correctly, WinFS didn't make it into the second round of Longhorn (e.g. what was to become Vista).
Sounds like they're due for a refresh so they can get some new patents on their filesystem to make sure all the device makers need to continue to pay them money.
That's what exFAT was for. This is probably to make it harder for non-Windows folks again since they can finally read/write to NTFS (stable since late 2.6.2x series for Linux; don't know about the others).
mklink can create symlinks (which were introduced with NT6.0's update to NTFS)/hardlink/dir junctions and is available out of the box since Vista/Server 2008. There's "fsutil hardlink" command on earlier systems, but to create directory junctions you had to install Resource Kit's linkd or Russinovich's Junction.
NTFS had that support for quite a while, and APIs to do it; just no user tools to support it until Microsoft decided it was the god of all inventions to use for managing DLLs in WinSXS. Since Vista, you can easily consume 3 or 4 times your actual disk space as the utilities provided by Microsoft for disk space don't account for them.
Citation needed. The last estimate I read was something like a 5% success rate. I used that to make fun of Criminal Minds tv show, which has a near 100% success rate. That's the way profilers want to be seen, but it doesn't work out like that. So if you have numbers, preferably in percentages rather than total successes with no context, that would be a good start.
While I agree, CI doesn't have a 100% rate, but yeah a pretty darned unbelievable rate of like 99% or something. (They let one get away every now and again.)
Everybody knows that their customers want to know such things because they asked in a quite vocal maner just after the troubles, and werre simply dismissed by RSA. So, now RSA issues a PR stating that their customers want to know if they are secure, and not teling if they gave any answer. Quite funny what some spin can create.
Anyway, why should anybody buy a product from RSA anymore?
It's not so much if they are secure, but how did they detect the breach, etc. That is some very important information for a lot of people - even people that don't use RSA products - as it can help detect or prevent security issues elsewhere. It's kind of like saying, "Your system had a Monkey B virus; what did you do to detect and remove it?"
Why should they become more comprehensible? They are a record by a professional for a professional, not for you - if you require them to become readable by any random person then you are going to create a lot more work for those writing the records, and possibly introduce ambiguity into records where a doctor doesn't want to write a thousand word essay to correctly describe a specific condition within a broad area of similar conditions, avoiding identifying the condition as a similar issue but cannot be treated as such due to preexisting problems when seven words of medical jargon would be more precise anyway.
It's like saying C should be written so that anyone downloading the Linux kernel can immediately understand what's going on. That isn't ever going to happen, even though the code is available - it's still aimed at those with a working knowledge of C, not Joe from the diner.
That's not to say that having your medical record has no benefit - it has loads.
Oddly enough though, in this case that little bit of extra work by the doctor's office (which could be done by a staff member or possibly even a computerized system) could aid in substantially reforming the health care system; e.g. by enabling patients to see that Doctor X didn't do anything so shouldn't be paid, while Doctor Z did all the work and should be. It also enables a whole bunch of other things.
I do agree though that patients should only have a copy; be it on USB, paper, or otherwise. (or the other way around - patients get the "original" and the doctor's keep a "copy" - however you want to define those two terms for the sake of the argument/task). There does need to be some integrity in the system maintained, such that modifications can be traced (to a reasonable degree), and doctor's have a method of verifying what they did order such that any crackpot with enough tools to modify the electronic copies couldn't simply make modifications to get what they want. That might require digital signatures, watermarks, etc be put in.
1. Setup the routers on their own isolated network (e.g. if the church run 192.168.x.x run it in 172.16.x.x, both with different netmasks) and have a central gateway that can then just push the wireless network directly to the internet; best if the routers are cabled directly to that system too if you can help it; otherwise someone with the right smarts might jump networks if they know enough about the other networks config. You could couple this with a MAC Address DHCP assignment for staff computers so that staff can use the wireless on the normal network if you like; but I'd suggest that you make them VPN into the other network instead for better security.
2. The ideas of Captive Portals, etc. are probably what you want as well.
So, it's not really a single solution - capture them into one network (e.g. 172.16.x.x); grant them Internet Access after they agree to your terms, and then allow VPN to the other network (e.g. 192.168.x.x).
No, for those apps that require a GUI interface, rather than running that GUI locally through your constrained low bandwidth connection, you launch the GUI on the server side, and make use of the server's broadband connection and remove your local client's low bandwidth connection from the equation. Read the last line of my post. I'm not suggesting it increases the bandwidth (although the parent did via a poorly worded response), but rather increases the bandwidth available to you for those apps that require a GUI, while removing your local client connection from the picture.
Your local client connection and its bandwidth is not removed from the picture. You are just reallocating what the bandwidth affects. Instead of it directly affecting the application, it's affecting the RDP session you are running instead. Instead of waiting on the data in the application, you are waiting on the ability to interface with the computer.
Now, to your point the way consumer grade ISPs work, you do end up with more bandwidth as you have a greater download speed than upload speed, and RDP will make better use of that scenario. But it nonetheless just reallocates what is being affected.
Slashdot Mirror
Of course, you might have a good ability to challenge a ticket on it by looking to see if the sign change itself was legal (e.g. authorized) or if someone just switched it trying to get more people to stop and leave the intersection clear that they already should have been doing.
That right there addresses the crux of my point. To tell if something is illegal or not, the clear markings on the road and the laws as written don't necessarily apply.
Actually, even if the sign was switched illegally, you're still bound by law to obey it as it still qualifies as a "posted signed". You're also bound to obey the written lawss as they are on the books.
However, that doesn't mean that in that situation if you find that it was illegally posted, that you can't get it challenge it on that ground - and if you find out who illegally posted it, they'll could get fined or jail time too. It's not a matter of ambiguity.
It also doesn't mean that an officer won't use their discression in how they apply the written laws. For example, in Pennsylvania the written laws is that you are speeding and the officers are to ticket you even if you are 1 MPH over the speed limit - which is obviously impractical, and while officers can ticket you that way, they don't usually - the usually wait for it to be 5 or 10 MPH over. But that doesn't mean they couldn't do it by the book and follow the written law 100% - they very well could, and you can't do a thing about it if you didn't follow it that way.
Or, at lease, the laws include the federal laws, the state laws, the town/county/parish laws, the minutes of whatever local body decided to put up the sign, the actual actions of whoever put up the sign, and all related case law. Even then you have no way of knowing how an eventual court case might turn out.
Doesn't matter. You're still bound by them all; with each level overriding those below it. That is, if a federal law says to do X and a state writes a conflicting law to do Y, then you're still bound to do X. Same between between Federal and local, and State and local. The lower levels of government can only refine what the upper levels legislate - not contradict it. It gets a little messy between State and Federal only because of the limited ability of the Federal government to regulate States, which has been drastically (and illegally) expanded over the last 50 years or so.
Essentially, if they put thirty-three stop lines on the same light, spaced 30 meters apart, and the town council approved it, the same traffic light would legally cover all those intersections over an entire kilometer (and it's on a long downhill grade, you can see the light about a kilometer away).
Yes. And unless there was something in the laws above them saying they can't do that then it'd be perfectly legal and you have to follow it.
The problem is, you're making an argument from common sense. You are not, I assume, a lawyer. For example, you say that of course you can take a right on red at any of those stop lines, but what are you basing that on? Aside from me mentioning that right turns on red at stop signs are legal in my state, what do you actually know about the laws in my state?
Correct, I am not a lawyer. However, in most states it is legal to make a right turn on red unless otherwise posted. Same for U-turns. One thing the federal government and states has done is make the driving laws as uniform as possible.
The law might be phrased in such a way that it describes an intersection where you can take a right turn on red and a second stop line for the same red light doesn't fit that description, but at the same time, the law doesn't say you can't have multiple stop lines for the same light. If that's the case, then it's a valid legal interpretation that you can only take a right turn on red at the first stop line, but it's also a valid in
You have to treat it just the same as the line at the stop light. If the light is red, then you have to stop there; if you can turn right on red, then by means do so. There is no ambiguity in there other than what you want to add. Yes, people may not pay enough attention to it since it is further from the light than it should be, but it is still nonetheless part of the intersection.
Of course, you might have a good ability to challenge a ticket on it by looking to see if the sign change itself was legal (e.g. authorized) or if someone just switched it trying to get more people to stop and leave the intersection clear that they already should have been doing.
There's a similar intersection where I live. The light sits just across the rail road tracks, on both sides of which are a road, and then another main road crosses all three. The one road only has stop signs. Yes, there is a "stop here on red" in two places for the road that crosses the tracks - one right before the tracks, and one before the side road with the stop signs. Don't dare treat the first "stop here on red" like a stop sign - they will ticket you.
That is NOT illegal. Its ill-advised by driver's ed; but it is NOT illegal. That is why the officer doesn't care.
There is no ambuity there. It has nothing to do with whether you see the light, and everything to do with whether or not you are blocking traffic from any direction - e.g. the cars to your left and right. If you haven't crossed the "stop here on red" line for the direction you're going, then you are still in the intersection, and thereby officially blocking it - even if no other cars have yet entered. Again, you're putting ambuity in there because it suits you, not because it is actually there.
Pot, kettle, Kettle, pot.
More like: Pot, Kettle, Cauldron; meet Stainless Steel Soup Pot. Stainless Steel Soup Pot, meet Pot, Kettle, and Cauldron.
Well, yeah - that Stainless Steel Soup Pot may be well used and have a bit of black on it too; but nothing like the Pot, Kettle, and Cauldron which were black even when brand new.
I'm sure the first step is to pump off as much fuel oil as possible.
I'm guessing it's not 120m tall. Even if it settled upright. Perhaps an Antenna will be left above water.
120m is roughtly 360 feet. According to Wikipedia it has 17 decks; figuring on that a deck is about 10 feet apart, that's 170 feet there, but there will also be space between the decks (which will probably be 3-5 feet) and some decks (especially the upper most and lowermost decks) will have a lot more space, not to mention the various engineering rooms in the lowermost sections, and double-hulls, etc. So it can easily be more than 360 feet tall.
Lets hope that whatever follows has the same longevity as VGA. In a world where we've invented USB 3 times (USB, mini USB and micro USB) with non-compatible connectors in just 11 years, the future does not look as good.
Wasn't re-invented; just added to in order to support multiple form factors. You don't find mini or micro USBs on desktop/laptop/server computers. You also don't find USB on phones or tablets, or other small form-factor devices.
While I like DVI and have a monitor that uses it, going HDMI only is not a big deal. HDMI is just DVI plus a little extra, for audio, and the cost of that "little extra" is already negligible.
This means that a DVI-DVI, HDMI-HDMI, and DVI-HDMI cable are the same price. I spent $5 on one a few years back.
No difference! Unbunch your panties
Except HDMI also interfaces with HCMI which is what content companies (RIAA, MPAA) really want you to have so that they can "close the analog hole". HDMI will also talk with HCMI devices, but announce that it is not HCMI and therefore block the content from the HCMI port. This is their ultimate goal. DVI was just a way to start towards that, and VGA was their enemy.
Right the ship, drain the fuel and leave it there. You only have to stop it from sinking, you don't need to make it seaworthy.
Correct - it doesn't have to be seaworthy - it just has to make it into a floating dry-dock (which is seaworthy) so that they can transport it to a proper place for repair or salvage.
It's on an underwater mountainside hung up on a rock protrusion. The bow and stern are slumping, but the center is maintaining height. It's back is likely broken.
Still, it supposedly only has another 120m to go to the next shelf bottom; so sinking it where it is doesn't necessarily make sense either - I'm pretty sure it's a lot taller than the water is deep there. But you may have a good point for not being able to salvage it. OTOH, they may be able to get it to a floating dry-dock to safely move it away - which would be easier than trying to float it all the way to an actual dry-dock - you'd only have to float it for a few days at most while you get it into the floating dry-dock.
It has nothing to do with ignorance and everything to do with what is available for managing networks with IPv6 installed. The fact is, there is a lot less support for doing things businesses deem critical for network management in IPv6 than there is for IPv4. Part of that is just the age and maturity of IPv6 and the various tools out there; but part of it is also by design.
For example, by design IPv6 was not suppose to have DHCP ever - it was suppose to be built into the network by the local system providing its MAC address or another number as the lower bits and then auto-detecting the upper bits (Link Local). As a result, they ignored DHCP for a long time - it's only come about in the last couple years.
Again, by design you were not suppose to ever using NAT'ing or other means of segregating networks or hiding a network (however large) behind a single IP (the purpose of NAT). They wanted everything on the public network. However, this means large security concerns as you now have a whole host of additional devices, etc. that would be on the network. Add to this the fact that at least early IPv6 (well, if you could 2009 still as being early IPv6) was known for getting out of firewalled networks - and yes, IPv6 firewalls were available (at least on Linux) at that point.
So there is no ignorance involved. It is a matter of various security concerns that primarily businesses (and gov't) have with controlling who is on their network, and who has access to what, and how the architecture of the network. The IPv6 backers have largely ignored much of that, or designed methods that are inadequate to address the real concerns - even by design removing functionality entirely that was desired and necesary. Now the "design" is getting hacked up to add those features as IPv6 won't be able to go forward without them - the recent advent of DHCPv6 being one example.
IPv4 was generally really simple; and you built tools to manage it. With IPv6 they tried too hard to build those things into IPv6 itself; thereby making it too complex. They should really have gone with a similar approach for IPv6 as they did for IPv4 - just keep IPv6 to addressing and let other standards, other tools do the rest.
Only if the firewall is incapable of dealing with IPv6. I'm sorry, but I don't see your argument of "X is rubbish if not fully implemented so let's not use X at all" as valid. Elements of it are going to be crap without hardware or software that supports it properly, but eventually it's going to be usable in more and more situations.
You're missing the point - that's how network adminstrators and (more importantly) their bosses are going to look at it that way and make the decision that way.
I certainly have full control over my firewall and what it supports (since it's a Linux-based server running Gentoo); so it's not as big an issue there from the firewall side; however, having the ability to control the network addressing is - I want my network to be private and fully controlled; no traffic gets in or out unless I say so. And that is (to an even greater extreme) how many large enterprises run their networks - so that would be a very valid issue for them; while it might not be for you.
That doesn't mean not testing it or working with it; but it will prevent mass migrations and support by from big companies.
Unfortunately, IPv6 will break a lot of firewalls and security etc. It has already been well shown that IPv6 will enable even computers on private networks to escape the firewalls in place, completely bypassing the security restrictions.
The issue is that IPv6 makes it really easy to have everything on the public network, and really hard to change that.
I had considered changing my home network over to IPv6 only, and then run a 6-to-4 gateway on my server. However, I quickly found out that controlling the network addresses was a HUGE problem. With IPv4, I assign each system its own static IPv4 address based on its MAC address; and the IPv4 address is tied to the internal DNS. I can do it completely transparently. Similar stuff for IPv6 is still in its infancy, with the pro-IPv6 people for a long time completely ignoring DHCP. (Yes, DHCPv6 is now available, but no where near as complete and functional as DHCP for IPv4.)
So a lot of the resistence to IPv6 has probably been due to the pro-IPv6 people's hatred for a lof the security, network management, etc. that people have come to love under IPv4. I will certainly run a 4-to-6 gateway for my internal network before giving up that kind of control, and I suspect many large organizations and their network nazi's will too.
Summary: IPv6 is its own worse enemy; but it's getting better. Just don't expect it to be your friend any time soon.
It's a result of the Civil Rights and Femmenists movements. Everything has to be as equal as possible or the ACLU, NAACP, NPR, and femmenist groups raise hell.
She's not even two yet and I hate pink. Like I said, she stays home with her dad who likes to dress her up like a dinosaur. Where the fuck did she pick up the stereotype that she should prefer the pink shirt to the blue shirt?
Well, to answer the GP's question - probably from all the pink baby gear she got at her baby showers, etc. There's just so much of it you can't help it. I've got a 11 month old son, and it's hard to find stuff for boys as something like 75% of the baby stuff is for girls. It's frustrating at times.
I suspect that liking pink is innate to boys and girls alike. I have seen little boys (less than 3yo) go for bright pink objects over any other color. I am led to assume that pink just feels like a vivid, yet soft and pleasant color to us - that is, before we males duly acquire proper male tastes, and grow a strong, healthy distaste for it.
Well, while it may have that its more a social thing for why boys tend to shun pink than anything else. Boy's tend to hate being called "girlie", etc by their peers, which is probably what drives it. So they'll probably be okay wearing pink or whatever until they get to preschool or even early elementary when those kinds of peer things really take off and they become social and want to be accepted; then they'll start shunning things just because they think it'll make them fit in better. Of course, you'll get the occassional kid that won't care and will go about things any way they please; but they're the exception not the rule - though if they are the most popular then it may dampen the effects on the others.
I mean come on that's been a problem for years right?
Why renamen man when you could rename info instead? At least then you get both man and woman together.
The reason for that should be pretty obvious - NTFS was supposed to replace HPFS in what was then still called OS/2 NT.
NTFS development started along with NT development in the late '80s. Back when IBM and Microsoft were still BFFs and *years* before they would have any thoughts about "compatibility".
NTFS was NOT jointly developed by Microsoft and IBM, HPFS was. Microsoft did NTFS as part of Windows NT after the split. And FYI - Windows has never really recognized the HPFS or HPFS+ file systems - both used by OS/2 and Mac OS, and instead calling them "corrupted" NTFS file sytems. Yes there are a lot of shared features between the two; but that probably has more to do with the fact that Microsoft worked on HPFS than anything else - they probably saw them as good features to have as a result, and thereby incorporated them. (Not to mention the marketing perspective.)
I'll also point out that Wikipedia disagrees with you as well (see NTFS Wiki article - just read the page source for blackout day) as to the origin of NTFS; while it does kind of agree in the assumption of why NTFS uses the same disk type as HPFS but for different reasons.
And they specifically used the same FS number as HPFS which Microsoft and IBM jointly developed for OS/2, and was also used by Apple for MacOS specifically to keep systems from being compatible.
So, watch them use partition table FS identifier 82 (Linux FS - Ext2/3/4) instead...for the same reason. However, that has typically only hurt Microsoft as everyone else figures out how to be detect the differents FS's on the actual partition, especially the Linux folks.
Are they actually going to release this one? I remember one of the big features of Vista was to be their new filesystem Win FS. Although, I guess Microsoft had enough criticisms to deal with in Vista that it could have been even more of a disaster to release a new filesystem with it.
WinFS was ditched before Vista development was started. Yes, it was part of the original Longhorn project; but that project after 3 years was tossed, and a new Longhorn project was started that became Vista, and then reved and became Win7; but if I recall correctly, WinFS didn't make it into the second round of Longhorn (e.g. what was to become Vista).
Sounds like they're due for a refresh so they can get some new patents on their filesystem to make sure all the device makers need to continue to pay them money.
That's what exFAT was for. This is probably to make it harder for non-Windows folks again since they can finally read/write to NTFS (stable since late 2.6.2x series for Linux; don't know about the others).
mklink can create symlinks (which were introduced with NT6.0's update to NTFS)/hardlink/dir junctions and is available out of the box since Vista/Server 2008. There's "fsutil hardlink" command on earlier systems, but to create directory junctions you had to install Resource Kit's linkd or Russinovich's Junction.
NTFS had that support for quite a while, and APIs to do it; just no user tools to support it until Microsoft decided it was the god of all inventions to use for managing DLLs in WinSXS. Since Vista, you can easily consume 3 or 4 times your actual disk space as the utilities provided by Microsoft for disk space don't account for them.
Citation needed. The last estimate I read was something like a 5% success rate. I used that to make fun of Criminal Minds tv show, which has a near 100% success rate. That's the way profilers want to be seen, but it doesn't work out like that. So if you have numbers, preferably in percentages rather than total successes with no context, that would be a good start.
While I agree, CI doesn't have a 100% rate, but yeah a pretty darned unbelievable rate of like 99% or something. (They let one get away every now and again.)
Everybody knows that their customers want to know such things because they asked in a quite vocal maner just after the troubles, and werre simply dismissed by RSA. So, now RSA issues a PR stating that their customers want to know if they are secure, and not teling if they gave any answer. Quite funny what some spin can create.
Anyway, why should anybody buy a product from RSA anymore?
It's not so much if they are secure, but how did they detect the breach, etc. That is some very important information for a lot of people - even people that don't use RSA products - as it can help detect or prevent security issues elsewhere. It's kind of like saying, "Your system had a Monkey B virus; what did you do to detect and remove it?"
Why should they become more comprehensible? They are a record by a professional for a professional, not for you - if you require them to become readable by any random person then you are going to create a lot more work for those writing the records, and possibly introduce ambiguity into records where a doctor doesn't want to write a thousand word essay to correctly describe a specific condition within a broad area of similar conditions, avoiding identifying the condition as a similar issue but cannot be treated as such due to preexisting problems when seven words of medical jargon would be more precise anyway.
It's like saying C should be written so that anyone downloading the Linux kernel can immediately understand what's going on. That isn't ever going to happen, even though the code is available - it's still aimed at those with a working knowledge of C, not Joe from the diner.
That's not to say that having your medical record has no benefit - it has loads.
Oddly enough though, in this case that little bit of extra work by the doctor's office (which could be done by a staff member or possibly even a computerized system) could aid in substantially reforming the health care system; e.g. by enabling patients to see that Doctor X didn't do anything so shouldn't be paid, while Doctor Z did all the work and should be. It also enables a whole bunch of other things.
I do agree though that patients should only have a copy; be it on USB, paper, or otherwise. (or the other way around - patients get the "original" and the doctor's keep a "copy" - however you want to define those two terms for the sake of the argument/task). There does need to be some integrity in the system maintained, such that modifications can be traced (to a reasonable degree), and doctor's have a method of verifying what they did order such that any crackpot with enough tools to modify the electronic copies couldn't simply make modifications to get what they want. That might require digital signatures, watermarks, etc be put in.
Either way, it's not a simple task.
1. Setup the routers on their own isolated network (e.g. if the church run 192.168.x.x run it in 172.16.x.x, both with different netmasks) and have a central gateway that can then just push the wireless network directly to the internet; best if the routers are cabled directly to that system too if you can help it; otherwise someone with the right smarts might jump networks if they know enough about the other networks config. You could couple this with a MAC Address DHCP assignment for staff computers so that staff can use the wireless on the normal network if you like; but I'd suggest that you make them VPN into the other network instead for better security.
2. The ideas of Captive Portals, etc. are probably what you want as well.
So, it's not really a single solution - capture them into one network (e.g. 172.16.x.x); grant them Internet Access after they agree to your terms, and then allow VPN to the other network (e.g. 192.168.x.x).
No, for those apps that require a GUI interface, rather than running that GUI locally through your constrained low bandwidth connection, you launch the GUI on the server side, and make use of the server's broadband connection and remove your local client's low bandwidth connection from the equation. Read the last line of my post. I'm not suggesting it increases the bandwidth (although the parent did via a poorly worded response), but rather increases the bandwidth available to you for those apps that require a GUI, while removing your local client connection from the picture.
Your local client connection and its bandwidth is not removed from the picture. You are just reallocating what the bandwidth affects. Instead of it directly affecting the application, it's affecting the RDP session you are running instead. Instead of waiting on the data in the application, you are waiting on the ability to interface with the computer.
Now, to your point the way consumer grade ISPs work, you do end up with more bandwidth as you have a greater download speed than upload speed, and RDP will make better use of that scenario. But it nonetheless just reallocates what is being affected.
ssh me@server1 scp /some/file.txt me@server2:/where/to/put/it
The GUI has nothing to do with the bottleneck you're referring to.
Now compare that to doing the same task over an RDP session; that's what the OP is talking about, and that's the fallacy.