Even in the event of pin breakoff, tweezers would work... A pin insert is a good idea and is used elsewhere in the industry, so it's not exactly new thinking, so I wonder why this LGA came up as intel's 'solution'.
Actually, that typically refers to polygons that can't be seen because something would be in front of it anyway.... Absolutely can not be seen no matter how good your perceiving entity is.
This refers to geometry detail that goes beyond the perception capabilities of the viewer...
That is my understanding. It sounds very much like common practice, but common practice requires that the modeler model enough geometry for the worst case perception. For example, something capable of having a bent or straight surface always has enough polygons to bend, but this technique sounds like the model would be adaptive and have simpler geometry depending on the model's current position/overall shape, and the flat surface would automatically be simplified.
I did not RTFA, so I could be completely off, but then again, who ever does?
You're right that to say the central point was DNA tracking, but some very relevant points were brought up.
For example, the main character became the prime suspect of a crime when his DNA was discovered near the scene. In this case, it is very much the same as race, where historically if a person of suspect race is seen near a crime scene, that person would become the prime suspect regardless of evidence.
The article says anyone 'arrested', not convicted, which gives me concern. People can get arrested and found to be truly innocent. Fingerprints aren't particularly invasive, simply a unique identifier, but DNA, as they say, could be examined for more information about what traits a person could carry. Granted, fingerprints aren't nearly as reliable and much easier to eradicate the presence of compared to DNA samples and the DNA bank would be useful, but once you go beyond tracking that which is merely unique from person to person to that which potentially lays out behavorial tendencies, health issues, etc, it becomes much more disconcerting.
An interesting film based on the premise of too much focus on DNA tracking is GATTACA.
I would assume it would be more because current sent through one leg to another would take a less lethal path (though a very scary sounding proposition) than from arms to feet... Of course, same applies to standing on your hands. If you were standing on your hands when such a high voltage difference occured and it went through your arms, it would likely go through the heart, or so I have heard.
One aspect that bothered me about the assembly course I did was that the professor had the exact opposite beliefs. He felt that no C compiler could ever beat a hand crafted assembly program in terms of speed/efficiency. His absolute measurment of this? LOC. If the resultant assembly had more LOC, it was obviously inefficient as there were more instructions to execute. Discarded was the fact that his provided 'dramatic example' leveraged several loops in the assembly code and the C compiled equivalent had none... His response was that the unrolled loops did nothing but take up system memory and disk storage, and that though he could not prove it, he was sure the assembly program would complete the task first...
Well, their alternative is a pure javascript validation system, which means I assume they are checking for things that are junk data, but would not be dangerous to their site (i.e. a part number consisting of a particular pattern of letters and numbers before running a query for it, which is an easy check but could put strain on a database unnecessarily).
The fact that the stated system was pure Javascript means the suggestion would be no more vulnerable than their original solution.
So, with respect to a third party vendor, yes, you should be able to put in feature requests like that for future products.
For the form validation, the most painful thing here is architecting it 'right'. To accomodate non-javascript visitors, you have the javascript set an extra parameter or something so the server side knows the server-side form validation shouldn't be required, and can skip. If that parameter is not set, the server side validation kicks in. Just like that a site that would be unusable to Javascript-disabled visitors becomes usable, and whenever possible the task of form validation is offloaded. If everyone disables javascript, it can become a problem, but that in and of itself would indicate something is seriously wrong with javascript implementations and they shouldn't be relied on anyway...
Designing to take advantage of Javascript is not the same as designing to *require* javascript.
You can have all those gee-whiz features that just simply don't happen to non-javascript visitors. The key is that the Javascript stuff not be required to provide all information visitor needs or have Javascript components as a requisite for processing visitor input.
You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.
True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.
OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...
Just to have a sizable community and a large ship to support the community. Generational ships where the people who arrive at the destination are the descendents of those who started. Requires people to realize and accept they will never see the new planet, and their children won't, and their children won't, etc...
Actually, it can be an issue. A significant issue for binary applications is that glibc differences and significant libraries having different ABIs across relatively minor version differences...
Remember the days of going from libc5 to glibc? That really accentuated this sort of difference between what distros choose and the impact on applications.
copper vs. fiber doesn't make a difference. It was likely in a hub environment or really oversubscribed network architecture.
I deal with copper ethernet networks with high end switches and they perform as well as the fiber configurations for significant runs. A significant problem indemic to ethernet networks is the use of crappy low end switches with low-end throughput overall, or stringing 48 port switches together with single cables. If you work with fiber, you *have* to buy better switches.
I disagree... Fiber is *not* the end-all be-all, and isn't even needed to do high speed. I work every day on copper media going up to 10 gigabit. The price point of copper media and supporting electronics will remain cheaper. Fiber has been around a long time and has not come down in price any. Crimping fiber is a pain in the ass compared with copper. And the fragility of fiber is another issue.
I don't understand fiber to each and every dorm room, that requires first that every customer purchase an expensive fiber card, and it increases maintenance costs. For the lengths associated with dorms, fiber is overkill (unless they are *massive* facilities. I could understand having fiber trunks between buildings or even between floors of a building, but the complexity and cost of a fiber to the dorm room solution is incredible and yields *zero* perceptible benefit. With copper, they don't require the students to purchase equipment they will probably never use outside of school at exhorbitant amounts.
Fiber is the solution for long-haul or extreme short latency for trunks, storage, extreme low latency HPC (ala Myrinet), or extreme security paranoid environments (EM leakage out of copper media is actually a concern for some really paranoid organizations). Throughput through copper isn't such a terrible problem, especially at mere gigabit speeds.
Sounds like an interesting concept, but I wonder how it will scale...
Assuming single-channel G/B operation, the best it could do is divide G/B users into three distinct segments (three non-overlapping frequency ranges at best). With this lack of flexibility a switched architecture seems not to yield much benefit... In fact, the alternitive use of overlapping channels to increase the overall 'bus' of the netork (the dual channel 108 mbps devices') seems more beneficial. If the net is only segmented into 3 segments, best case, and any given two hosts on the network communicate, there is a 33% chance they are on the same segment anyway, and the switched benefit isn't had. With dual channel, single segment, sure there is a 100% chance for contention in that case, but far more bandwidth available, and much better performance in wireless to lan communication (which is 98% of usage anyway).
Of course, it could be different from what I'm picturing, maybe it is more akin to a managed hub, where packets are only retransmitted to each host on 'switch-like' rules, but it remains the standard single-media solution. Perhaps kept very switchlike by different encryption keys per host, but ultimately the media is still shared in a hub fashion, so the typical network performance benefits of switched ethernet networks are not there to be had.. Of course, more intelligently handling mixed B/G devices could be the case, which would be a good thing..
Anyone know any more details about what they are meaning by a 'switched wireless network'? It certainly could be an interesting concept if the standard had more non-overlapping channels...
One time I was administering a school network consisting mainly of SunOS systems.
We had recently gotten HP-UX systems and at the time the HP-UX systems were not able to access NFS mounts off the SunOS servers (don't remember ultimate reason, it's been a while).
Anyway, in the midst of working the problem, before I truly had a good idea of exactly what was wrong, a girl comes up and asks what is wrong with the network, and I explain: 'Our network we have, it smokes crack, and these new systems, well, they are also smoking crack, but it's a different crack and we need to get them to coordinate their crack smoking more...'
She gets a bit insulted and indignant, thinking I'm talking down to her because she's a girl and not a sysadmin or anything and says: 'I can handle a more technical explanation than that!'
And my truthful answer: 'But I can't'.
She quickly laughed, smiled, and was reassured I wasn't truly talking down to her, I just had no clue....
My relative works for a city government office. She had the recurring problem of not being able to login to the network services when she came in at 8 a.m, but could connect at 10 a.m. and such. The explanation given 'your computer needs to warm up before it can use it's network card'.
Red Hat is a changing environment. Now they want people to buy their EL distribution and it is very much in their best interest to just toss Fedora out there and let the world test it, and for every fixed feature, they move something else to the bleeding edge until the community fixes it for them.
Then they bundle up all the fixed enhacements and sell them in EL....
As soon as they moved to make the brands more distinct and made a clear statement that those serious about a stable, reliable environment buy EL, it was clear this would be the result.
Unless a distro is either driven by a non-profit organization (Debian, Gentoo), or is a revenue stream for a professional Linux company (SuSE, and Red Hat Enterprise Linux), you are going to see this. Fedora represents a huge conflict of interest at its core, Red Hat wants it to be a testbed platform for Enterprise Linux, and users want a nice, stable system. Without a few of these problems, it would detract from potential EL customers.
I run 2.6 SMP kernel w/ PS/2 and Xorg and basically all this stuff Fedora uses, and it works fine, with gentoo.
I have a 15" laptop at 1600x1200, and it is great. The key is that X is configured to know the DPI and the fonts are rendered with much more definition (crisper lines, smoother curves).
3D games are another area where high resolution can lead to a smoother experience, so long as the game has little raster-font content.
Combine this with a more and more vector based interface, and you get a lot more flexibility. High resolution small displays no longer have to mean unreadable, they can mean much higher quality text and graphics.
Additionally, I can work with large numbers of windows or large spreadsheets and such by scaling fonts back down and still be able to work with it, albeit it less comfortably. It just feels right.
I also have a 21.4" flatpanel on my desk at 1600x1200, and for the most part the fonts are no larger, just more content can fit because of the DPI awareness (though non-vector images are much more bearable on that screen, but I actually see fewer and fewer things that matter in that format that have so much detail that it matters).
But it scales at worst case no worse than http/ftp so long as the hosting providers normally providing http/ftp allocate equal resources to serving bittorrents. When you are the only user of an http/ftp site, you get satisfactory speeds, so bittorrent would do fine for that scenario. Times like this where http/ftp services would crumble under the load, bittorrent offloads the work effectively and yields better download speeds than http/ftp do when there is only one client.
The thing with bittorrent is that you can get a small seed from an official source and be more assured that the content you are downloading is, in fact, what you want and not a trojan with the same name that turned up on some P2P network search. MD5 sums can help this, but it means in the event of an incorrect download, you've wasted your time and bandwidth. BitTorrent provides a distribution method with more verifiable authenticity before downloading than most P2P networks, and that is very valuable for this application.
Looking at just the letters is misleading. The letters are on a monument with a mirror image of a known painting, and even within the letters, the D and M are positioned differently, and there are the words 'Et in arcadia ego' with the image.
Add to that that other aspects of the monument may be significant, or there may be significance in the context of other monuments in the garden and/or other entities.
Now as to whether it will be solved, can be solved without knowledge of an inside joke, or even contains interesting subject matter at all is one issue. If it does have meaning, I would give it better odds of being figured out than a plain 10-letter inscription.
Even in the event of pin breakoff, tweezers would work... A pin insert is a good idea and is used elsewhere in the industry, so it's not exactly new thinking, so I wonder why this LGA came up as intel's 'solution'.
Actually, that typically refers to polygons that can't be seen because something would be in front of it anyway.... Absolutely can not be seen no matter how good your perceiving entity is.
This refers to geometry detail that goes beyond the perception capabilities of the viewer...
That is my understanding. It sounds very much like common practice, but common practice requires that the modeler model enough geometry for the worst case perception. For example, something capable of having a bent or straight surface always has enough polygons to bend, but this technique sounds like the model would be adaptive and have simpler geometry depending on the model's current position/overall shape, and the flat surface would automatically be simplified.
I did not RTFA, so I could be completely off, but then again, who ever does?
You're right that to say the central point was DNA tracking, but some very relevant points were brought up.
For example, the main character became the prime suspect of a crime when his DNA was discovered near the scene. In this case, it is very much the same as race, where historically if a person of suspect race is seen near a crime scene, that person would become the prime suspect regardless of evidence.
The article says anyone 'arrested', not convicted, which gives me concern. People can get arrested and found to be truly innocent. Fingerprints aren't particularly invasive, simply a unique identifier, but DNA, as they say, could be examined for more information about what traits a person could carry. Granted, fingerprints aren't nearly as reliable and much easier to eradicate the presence of compared to DNA samples and the DNA bank would be useful, but once you go beyond tracking that which is merely unique from person to person to that which potentially lays out behavorial tendencies, health issues, etc, it becomes much more disconcerting.
An interesting film based on the premise of too much focus on DNA tracking is GATTACA.
I would assume it would be more because current sent through one leg to another would take a less lethal path (though a very scary sounding proposition) than from arms to feet... Of course, same applies to standing on your hands. If you were standing on your hands when such a high voltage difference occured and it went through your arms, it would likely go through the heart, or so I have heard.
That's 'l337ism' for you.....
One aspect that bothered me about the assembly course I did was that the professor had the exact opposite beliefs. He felt that no C compiler could ever beat a hand crafted assembly program in terms of speed/efficiency. His absolute measurment of this? LOC. If the resultant assembly had more LOC, it was obviously inefficient as there were more instructions to execute. Discarded was the fact that his provided 'dramatic example' leveraged several loops in the assembly code and the C compiled equivalent had none... His response was that the unrolled loops did nothing but take up system memory and disk storage, and that though he could not prove it, he was sure the assembly program would complete the task first...
Well, their alternative is a pure javascript validation system, which means I assume they are checking for things that are junk data, but would not be dangerous to their site (i.e. a part number consisting of a particular pattern of letters and numbers before running a query for it, which is an easy check but could put strain on a database unnecessarily).
The fact that the stated system was pure Javascript means the suggestion would be no more vulnerable than their original solution.
So, with respect to a third party vendor, yes, you should be able to put in feature requests like that for future products.
For the form validation, the most painful thing here is architecting it 'right'. To accomodate non-javascript visitors, you have the javascript set an extra parameter or something so the server side knows the server-side form validation shouldn't be required, and can skip. If that parameter is not set, the server side validation kicks in. Just like that a site that would be unusable to Javascript-disabled visitors becomes usable, and whenever possible the task of form validation is offloaded. If everyone disables javascript, it can become a problem, but that in and of itself would indicate something is seriously wrong with javascript implementations and they shouldn't be relied on anyway...
Designing to take advantage of Javascript is not the same as designing to *require* javascript.
You can have all those gee-whiz features that just simply don't happen to non-javascript visitors. The key is that the Javascript stuff not be required to provide all information visitor needs or have Javascript components as a requisite for processing visitor input.
You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.
True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.
OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...
Just to have a sizable community and a large ship to support the community. Generational ships where the people who arrive at the destination are the descendents of those who started. Requires people to realize and accept they will never see the new planet, and their children won't, and their children won't, etc...
Actually, it can be an issue. A significant issue for binary applications is that glibc differences and significant libraries having different ABIs across relatively minor version differences...
Remember the days of going from libc5 to glibc? That really accentuated this sort of difference between what distros choose and the impact on applications.
copper vs. fiber doesn't make a difference. It was likely in a hub environment or really oversubscribed network architecture.
I deal with copper ethernet networks with high end switches and they perform as well as the fiber configurations for significant runs. A significant problem indemic to ethernet networks is the use of crappy low end switches with low-end throughput overall, or stringing 48 port switches together with single cables. If you work with fiber, you *have* to buy better switches.
I disagree... Fiber is *not* the end-all be-all, and isn't even needed to do high speed. I work every day on copper media going up to 10 gigabit. The price point of copper media and supporting electronics will remain cheaper. Fiber has been around a long time and has not come down in price any. Crimping fiber is a pain in the ass compared with copper. And the fragility of fiber is another issue.
I don't understand fiber to each and every dorm room, that requires first that every customer purchase an expensive fiber card, and it increases maintenance costs. For the lengths associated with dorms, fiber is overkill (unless they are *massive* facilities. I could understand having fiber trunks between buildings or even between floors of a building, but the complexity and cost of a fiber to the dorm room solution is incredible and yields *zero* perceptible benefit. With copper, they don't require the students to purchase equipment they will probably never use outside of school at exhorbitant amounts.
Fiber is the solution for long-haul or extreme short latency for trunks, storage, extreme low latency HPC (ala Myrinet), or extreme security paranoid environments (EM leakage out of copper media is actually a concern for some really paranoid organizations). Throughput through copper isn't such a terrible problem, especially at mere gigabit speeds.
Sounds like an interesting concept, but I wonder how it will scale...
Assuming single-channel G/B operation, the best it could do is divide G/B users into three distinct segments (three non-overlapping frequency ranges at best). With this lack of flexibility a switched architecture seems not to yield much benefit... In fact, the alternitive use of overlapping channels to increase the overall 'bus' of the netork (the dual channel 108 mbps devices') seems more beneficial. If the net is only segmented into 3 segments, best case, and any given two hosts on the network communicate, there is a 33% chance they are on the same segment anyway, and the switched benefit isn't had. With dual channel, single segment, sure there is a 100% chance for contention in that case, but far more bandwidth available, and much better performance in wireless to lan communication (which is 98% of usage anyway).
Of course, it could be different from what I'm picturing, maybe it is more akin to a managed hub, where packets are only retransmitted to each host on 'switch-like' rules, but it remains the standard single-media solution. Perhaps kept very switchlike by different encryption keys per host, but ultimately the media is still shared in a hub fashion, so the typical network performance benefits of switched ethernet networks are not there to be had.. Of course, more intelligently handling mixed B/G devices could be the case, which would be a good thing..
Anyone know any more details about what they are meaning by a 'switched wireless network'? It certainly could be an interesting concept if the standard had more non-overlapping channels...
They actually (at least used to) have that quote large on a wall of the main lobby of Red Hat's HQ. One of the things I noticed on a visit...
One time I was administering a school network consisting mainly of SunOS systems.
We had recently gotten HP-UX systems and at the time the HP-UX systems were not able to access NFS mounts off the SunOS servers (don't remember ultimate reason, it's been a while).
Anyway, in the midst of working the problem, before I truly had a good idea of exactly what was wrong, a girl comes up and asks what is wrong with the network, and I explain:
'Our network we have, it smokes crack, and these new systems, well, they are also smoking crack, but it's a different crack and we need to get them to coordinate their crack smoking more...'
She gets a bit insulted and indignant, thinking I'm talking down to her because she's a girl and not a sysadmin or anything and says: 'I can handle a more technical explanation than that!'
And my truthful answer: 'But I can't'.
She quickly laughed, smiled, and was reassured I wasn't truly talking down to her, I just had no clue....
My relative works for a city government office. She had the recurring problem of not being able to login to the network services when she came in at 8 a.m, but could connect at 10 a.m. and such. The explanation given 'your computer needs to warm up before it can use it's network card'.
Red Hat is a changing environment. Now they want people to buy their EL distribution and it is very much in their best interest to just toss Fedora out there and let the world test it, and for every fixed feature, they move something else to the bleeding edge until the community fixes it for them.
Then they bundle up all the fixed enhacements and sell them in EL....
As soon as they moved to make the brands more distinct and made a clear statement that those serious about a stable, reliable environment buy EL, it was clear this would be the result.
Unless a distro is either driven by a non-profit organization (Debian, Gentoo), or is a revenue stream for a professional Linux company (SuSE, and Red Hat Enterprise Linux), you are going to see this. Fedora represents a huge conflict of interest at its core, Red Hat wants it to be a testbed platform for Enterprise Linux, and users want a nice, stable system. Without a few of these problems, it would detract from potential EL customers.
I run 2.6 SMP kernel w/ PS/2 and Xorg and basically all this stuff Fedora uses, and it works fine, with gentoo.
In soviet union?
No, just the opposite, he *was* counting from zero, hence the 939... Counting from 1 instead of zero as an error would give too high a number.
I have a 15" laptop at 1600x1200, and it is great. The key is that X is configured to know the DPI and the fonts are rendered with much more definition (crisper lines, smoother curves).
3D games are another area where high resolution can lead to a smoother experience, so long as the game has little raster-font content.
Combine this with a more and more vector based interface, and you get a lot more flexibility. High resolution small displays no longer have to mean unreadable, they can mean much higher quality text and graphics.
Additionally, I can work with large numbers of windows or large spreadsheets and such by scaling fonts back down and still be able to work with it, albeit it less comfortably. It just feels right.
I also have a 21.4" flatpanel on my desk at 1600x1200, and for the most part the fonts are no larger, just more content can fit because of the DPI awareness (though non-vector images are much more bearable on that screen, but I actually see fewer and fewer things that matter in that format that have so much detail that it matters).
But it scales at worst case no worse than http/ftp so long as the hosting providers normally providing http/ftp allocate equal resources to serving bittorrents. When you are the only user of an http/ftp site, you get satisfactory speeds, so bittorrent would do fine for that scenario. Times like this where http/ftp services would crumble under the load, bittorrent offloads the work effectively and yields better download speeds than http/ftp do when there is only one client.
The thing with bittorrent is that you can get a small seed from an official source and be more assured that the content you are downloading is, in fact, what you want and not a trojan with the same name that turned up on some P2P network search. MD5 sums can help this, but it means in the event of an incorrect download, you've wasted your time and bandwidth. BitTorrent provides a distribution method with more verifiable authenticity before downloading than most P2P networks, and that is very valuable for this application.
Looking at just the letters is misleading. The letters are on a monument with a mirror image of a known painting, and even within the letters, the D and M are positioned differently, and there are the words 'Et in arcadia ego' with the image.
Add to that that other aspects of the monument may be significant, or there may be significance in the context of other monuments in the garden and/or other entities.
Now as to whether it will be solved, can be solved without knowledge of an inside joke, or even contains interesting subject matter at all is one issue. If it does have meaning, I would give it better odds of being figured out than a plain 10-letter inscription.