Good old google shows a relatively interesting page with respect to this with more potential background: http://www.veling.nl/anne/templars/re nnes-sion.htm l
With respect to how much info, it could contain a lot. There is more to it than ten letters, there is the picture (a mirror image of a known painting) and placement of the letters (the D and M are not in line with the rest), and of course the other words 'Et in arcadia ego'.
Beyond that, it could even have meaning in context in other monuments in the garden or, well anything...
There could be a lot of meaning in it, or just a dedication, or some artist with a weird whim that meant nothing...
The speed of most major ISOs from http/ftp is good because some organization with fat pipes can back it up *and* they are sporadically popular, so most of the time not many people are needing to get it....
Now with torrents, people with less beefy hosting services can publish content. When a new release of a distro comes out, it used to be I waited 2-3 days for the sites to settle down, but that is now the peak time for torrents to work better. In fact, if the same resource used to serve up http/ftp requests is used to serve torrent, the torrent should perform at worst case no wore than the http server, and during congestion has a recourse to scale better than http/ftp servers ever could. As it stands now, most places with that sort of resource don't take bittorrent seriously enough to allocate the same resources to it, so things can degrade to a few puny clients hosting the content indexed by a torrent. Understandably, as all the torrent interfaces I have seen to date are heavily individual file oriented and hosting many torrent files at once doesn't scale as neatly in terms of manageability as web or ftp servers, but that is a matter of a mature torrent-oriented server application being developed (I would *love* to be proven wrong, it would be very cool to have an integrated torrent hosting environment to help my puny pipe for some large content I serve up that is too unwieldy to administrate many torrent sessions for).
As to the >3KB/sec, I haven't seen it that bad on almost any torrent *except* when behind a non-configured nat or firewall. I'm not sure, but it seems like you can grab from a greater resource pool if you can allow direct connects to your client. If this is your circumstance, you should try researching the firewall configuration a bit and experiment. It is truly an awesome distribution scheme.
Leave a 'translucent' thing over a window with updating contents (i.e. a make), and if the contents covered by the thing don't update.....
That is my beef with the 'translucent' windows in KDE and the like, it is useless because you can't leverage it to monitor something in the background while working on something else. You just see whatever the widget set grabbed at the time the widget was created. Granted, without hardware support accessible, it will be impossible to properly do it.
With respect to the memory, at least this box has 32 GB of memory and 4-way Opteron. I know, still no where near the big iron, but very respectable at the price points OEMs are selling them for. Put Myrinet or Infiniband in these suckers for the money you save by not going Itanium, and you have a cluster configuration that scales really well.
Itanium is a fascinating architecture, but Intel *has* to do something about power consumption, cooling, and just plain cost before it can be a good competitor to other systems. The price difference between cooling, power, and the initial price and the competitors means competing configurations equally priced either have many many more nodes or a much better interconnect between nodes.
Arg, I hate hate reiserfs. It has even with the latest incarnations of distros been crash-prone relative to other filesystems, and more painful to recover than other filesystems in the event of a crash (>90% of the time when the fs needs help, it needs to rebuild tree, and read-only mount *still* screws that up, so you have to boot rescue)....
XFS also I've hit numerous issues (seems not to track free space correctly in near-full conditions, and will panic when it tries to write as it suddenly realizes the fs is really full!). My test was in near-full 360 GB filesystem, make a 500 MB file, delete it, remake it, delete it. Now you should be at the same spot, but you magically have nealy 500MB extra free space according to du.. Really flaky...
I have good experience out of JFS and ext3 with respect to reliability, though ext3 has been a bit more sluggish.
I care about performance, but reliability takes priority.
Well, beyond anecdotes I can give, the fact that Nocona will be an x86_64 chip shows that at least Intel is thinking Opteron/Athlon64 has had overwhelming success. Intel envisioned ia64 being the next logical step for desktops/workstations, but no one is going there. Starting from scratch to get rid of legacy baggage sounds great, but the market at large won't make the tradeoffs.
As to major OS, my livelihood is in HPC Linux configurations and Opteron systems are a hot item there, so there's your 'major OS'. It is on the same order of magnitude as the other 64-bit OSs (AIX, HP-UX, et al have no more market than Linux). In the field of price-performance, Opteron has been incredible, and thus popular in clusters (the ability to run legacy 32-bit within the 64-bit platform is a huge bonus to environments where occasionally a binary-only application is needed, but price-performance has been the dominant reason). HPC is essentially my restricted view of AMD success, so it may be skewed (HPC is a relative niche compared to the general desktop world).
As to Windows (the only significantly large market share among desktop OS), I think the current plan still has x86_64 Windows beating Nocona to market, so for a time the only 64-bit Windows platform capable of running 32-bit apps at native speeds will be AMD's.
I sound like an AMD fanboy, and ultimately I suppose I am (hey, they gave me a free T-shirt and Intel just gave me a cheap pen, I have good reason, see!), but AMD has really done a great job to date and as their market share approaches Intel, the customers are seeing more and more benefit. AMD is of course innovating quickly to stand out in Intel-architecture world, and Intel is innovating quickly to keep from losing. For the first time Intel has let another company define where they are going next (EM64T a.k.a. x86_64) and it shows they are really pained to admit it, you *never* see AMD or x86_64 in any of their releases.
First, I'm quite confident they have dual-core in the pipelines and I'm actually surprised they've released no public roadmaps to show this, especially to counter this Intel announcement.
Now as to the rest, what the hell?
1) They did not release 64-bit chips before anyone cared, UltraSparc, Power, Itanium, MIPS, Alpha, PA-RISC, et. al. were playing in this field already, some for many many years and there has been a long standing need for 64-bit tech.
2) 'crippled' the technology is one word for it, seeing as how it has been overwhelmingly popular and a home run for AMD (now we see Intel 'playing catch up' with ia32e, em64t, or whatever Intel wants to call x86_64 when *they* do it in Nocona). I admit, it is a really annoying architecture to live with the legacy of, but the market forces are speaking. Itanium tried to deny the market and start from scratch, and has had very low popularity, and now Nocona being x86_64 compatible is a testament to AMD's strategy and success.
It is more than annoying, the pirate community is so large it can be devastating. You make the comparison of Direct TV cheater cards, but those dishes cannot significantly degrade the service of other customers in the same way a networked computer can degrade network performance for a whole community.
Another poster had an idea which would make more sense. If MS truly doesn't want these people to pirate their platform and can reliably detect when such people attempt to get/install patches, why not have a branch that disables all functionality? (i.e. requires reboot and suddenly, it will do nothing more than a screen demanding proof of purchase before loading the system back up).
No, really, it is not likely at all OEMs can save much money by shipping Linux instead of Windows.
The key is support. If they slap a free distro on there, they would almost certainly have to assume a beefier support organization to stay competitive. That beefing-up would probably go above and beyond the cost of Windows copies and support. If they package a commercial distribution where they can always resort to the vendor for complex support situations, the price they pay for that distro is likely to be on par with the deep-discounted OEM Windows copies they install today.
Now if/when the market of users who want Linux over Windows bundled grows significantly, the vendors with Linux preloads enjoy a larger market until everyone else does it and ships more product. There is the incentive for Linux bundling, not strict cost savings.
I like Linux, I use it exclusively for work and home. However I know through my work the challenges that face a company trying to sell supported versions of Linux. Even if it is the greatest thing on Earth, a support contingency is needed for customers to be comfortable.
Well, along with the other responses in the thread, a key phrase in your post is 'a platform that...', meaning a singular environment that manages to attain Windows compatibility. That would still deny users choice and customization.
When you write an application against portable APIs, you give users freedom to choose what platform suits their needs best and run your application. Whenever a platfrom is dictated to the user for the sake of the applications, it is suboptimal. Whether the base is free or Free or whatever, it is still a lack of choice at stake. I write to APIs like wxWidgets and SDL, and my applications a) run on whatevere platform I want without significant porting effort, though more testing effort is needed, b) run at native speeds (unlike the Java approach), and c) fits in with the look and feel of other non-crossplatform apps (also distinct from the Java approach).
That isn't a point of contention, read at *least* the summary before going off the handle. This is not about security updates for the benefit of the pirate end user, but the impact of having pirate end users incapable of getting security updates propogating worms that make the rest of the good community suffer.
On remote-exploit security updates, now that I see this circumstance, I think they should apply no matter what. Now feature enhancements and reliability fixes for the end user, those should be denied. Those fixes not being applied are far more annoying to the typical end user anyway, so MS would improve the community by fixing even the pirate systems in the ways that impact the community, but keep things hard for the pirate users by leaving their system extra buggy (even above and beyond the normal Windows experience).
Slashdot is making a mountain out of this molehill of an announcement. This is simply a different Ethernet Switch Module for a bladecenter chassis. Switch goes bad or becomes antiquated, pull it and replace it. Just means cisco will now provide a switch that conforms to the required form factor and connector. This complements the current D-Link offering (I think their switch is D-Link right now, either that or Nortel, can't remember).
Ok, with that out of the range, it isn't so simple as 'just write one'. If that were the case, there are already many many players out there that are technically capable of playing DVDs that could be 'legitimized' (mplayer, xine, ogle come to mind).
However, the MPAA isn't interested in that path. Open Source and MPAA don't mesh. An open development community cannot write a truly closed-source application by definition.
The only path would be a small community to come together, sign NDAs from the get go, never consult existing open source implementation in writing their code, and pay a significant monetary sum to the MPAA for their trouble.
As to a free video format, some exist. With container formats, I'm not sure any of the major ones are very closed or restricted, but certainly.ogg (which can contain video streams, and by convention gets.ogm in such a situation) and matroska are open....
There are also a few open codecs. The most successful by far would have to be xvid. The Ogg people have picked up a codec from On2 and their version is Theora. There are probably more, but that covers it.
Now the dynamic bitrate idea is cool, and vorbis has it for audio. I don't know of that in any video, Tarkin would've been the best bet, but all mention of it seems to be gone from xiph's site, which likely indicates it just isn't going to happen.
Slashdot Mirror
Good old google shows a relatively interesting page with respect to this with more potential background:e nnes-sion.htm l
http://www.veling.nl/anne/templars/r
Actually, the code is done before select or start.
Select selected the two player option and the start was simply the same as normally starting.
Only on slashdot would such a debate arise....
The D and M are below the rest it says in the article.
With respect to how much info, it could contain a lot. There is more to it than ten letters, there is the picture (a mirror image of a known painting) and placement of the letters (the D and M are not in line with the rest), and of course the other words 'Et in arcadia ego'.
Beyond that, it could even have meaning in context in other monuments in the garden or, well anything...
There could be a lot of meaning in it, or just a dedication, or some artist with a weird whim that meant nothing...
The speed of most major ISOs from http/ftp is good because some organization with fat pipes can back it up *and* they are sporadically popular, so most of the time not many people are needing to get it....
Now with torrents, people with less beefy hosting services can publish content. When a new release of a distro comes out, it used to be I waited 2-3 days for the sites to settle down, but that is now the peak time for torrents to work better. In fact, if the same resource used to serve up http/ftp requests is used to serve torrent, the torrent should perform at worst case no wore than the http server, and during congestion has a recourse to scale better than http/ftp servers ever could. As it stands now, most places with that sort of resource don't take bittorrent seriously enough to allocate the same resources to it, so things can degrade to a few puny clients hosting the content indexed by a torrent. Understandably, as all the torrent interfaces I have seen to date are heavily individual file oriented and hosting many torrent files at once doesn't scale as neatly in terms of manageability as web or ftp servers, but that is a matter of a mature torrent-oriented server application being developed (I would *love* to be proven wrong, it would be very cool to have an integrated torrent hosting environment to help my puny pipe for some large content I serve up that is too unwieldy to administrate many torrent sessions for).
As to the >3KB/sec, I haven't seen it that bad on almost any torrent *except* when behind a non-configured nat or firewall. I'm not sure, but it seems like you can grab from a greater resource pool if you can allow direct connects to your client. If this is your circumstance, you should try researching the firewall configuration a bit and experiment. It is truly an awesome distribution scheme.
Leave a 'translucent' thing over a window with updating contents (i.e. a make), and if the contents covered by the thing don't update.....
That is my beef with the 'translucent' windows in KDE and the like, it is useless because you can't leverage it to monitor something in the background while working on something else. You just see whatever the widget set grabbed at the time the widget was created. Granted, without hardware support accessible, it will be impossible to properly do it.
With respect to the memory, at least this box has 32 GB of memory and 4-way Opteron. I know, still no where near the big iron, but very respectable at the price points OEMs are selling them for. Put Myrinet or Infiniband in these suckers for the money you save by not going Itanium, and you have a cluster configuration that scales really well.
Itanium is a fascinating architecture, but Intel *has* to do something about power consumption, cooling, and just plain cost before it can be a good competitor to other systems. The price difference between cooling, power, and the initial price and the competitors means competing configurations equally priced either have many many more nodes or a much better interconnect between nodes.
Arg, I hate hate reiserfs. It has even with the latest incarnations of distros been crash-prone relative to other filesystems, and more painful to recover than other filesystems in the event of a crash (>90% of the time when the fs needs help, it needs to rebuild tree, and read-only mount *still* screws that up, so you have to boot rescue)....
XFS also I've hit numerous issues (seems not to track free space correctly in near-full conditions, and will panic when it tries to write as it suddenly realizes the fs is really full!). My test was in near-full 360 GB filesystem, make a 500 MB file, delete it, remake it, delete it. Now you should be at the same spot, but you magically have nealy 500MB extra free space according to du.. Really flaky...
I have good experience out of JFS and ext3 with respect to reliability, though ext3 has been a bit more sluggish.
I care about performance, but reliability takes priority.
What's a google? I know what a *googol* is in terms of numbers, but google is not a number...
Here.
Bill Gates is already in, so he is not a missing option...
One nitpcik, it would be a *moot* point...
Where's the s?
Well, beyond anecdotes I can give, the fact that Nocona will be an x86_64 chip shows that at least Intel is thinking Opteron/Athlon64 has had overwhelming success. Intel envisioned ia64 being the next logical step for desktops/workstations, but no one is going there. Starting from scratch to get rid of legacy baggage sounds great, but the market at large won't make the tradeoffs.
As to major OS, my livelihood is in HPC Linux configurations and Opteron systems are a hot item there, so there's your 'major OS'. It is on the same order of magnitude as the other 64-bit OSs (AIX, HP-UX, et al have no more market than Linux). In the field of price-performance, Opteron has been incredible, and thus popular in clusters (the ability to run legacy 32-bit within the 64-bit platform is a huge bonus to environments where occasionally a binary-only application is needed, but price-performance has been the dominant reason). HPC is essentially my restricted view of AMD success, so it may be skewed (HPC is a relative niche compared to the general desktop world).
As to Windows (the only significantly large market share among desktop OS), I think the current plan still has x86_64 Windows beating Nocona to market, so for a time the only 64-bit Windows platform capable of running 32-bit apps at native speeds will be AMD's.
I sound like an AMD fanboy, and ultimately I suppose I am (hey, they gave me a free T-shirt and Intel just gave me a cheap pen, I have good reason, see!), but AMD has really done a great job to date and as their market share approaches Intel, the customers are seeing more and more benefit. AMD is of course innovating quickly to stand out in Intel-architecture world, and Intel is innovating quickly to keep from losing. For the first time Intel has let another company define where they are going next (EM64T a.k.a. x86_64) and it shows they are really pained to admit it, you *never* see AMD or x86_64 in any of their releases.
First, I'm quite confident they have dual-core in the pipelines and I'm actually surprised they've released no public roadmaps to show this, especially to counter this Intel announcement.
Now as to the rest, what the hell?
1) They did not release 64-bit chips before anyone cared, UltraSparc, Power, Itanium, MIPS, Alpha, PA-RISC, et. al. were playing in this field already, some for many many years and there has been a long standing need for 64-bit tech.
2) 'crippled' the technology is one word for it, seeing as how it has been overwhelmingly popular and a home run for AMD (now we see Intel 'playing catch up' with ia32e, em64t, or whatever Intel wants to call x86_64 when *they* do it in Nocona). I admit, it is a really annoying architecture to live with the legacy of, but the market forces are speaking. Itanium tried to deny the market and start from scratch, and has had very low popularity, and now Nocona being x86_64 compatible is a testament to AMD's strategy and success.
Yes.
And btw, I only have a 2D barcode on my license, my cereal only has 1D barcodes...
It is more than annoying, the pirate community is so large it can be devastating. You make the comparison of Direct TV cheater cards, but those dishes cannot significantly degrade the service of other customers in the same way a networked computer can degrade network performance for a whole community.
Another poster had an idea which would make more sense. If MS truly doesn't want these people to pirate their platform and can reliably detect when such people attempt to get/install patches, why not have a branch that disables all functionality? (i.e. requires reboot and suddenly, it will do nothing more than a screen demanding proof of purchase before loading the system back up).
No, really, it is not likely at all OEMs can save much money by shipping Linux instead of Windows.
The key is support. If they slap a free distro on there, they would almost certainly have to assume a beefier support organization to stay competitive. That beefing-up would probably go above and beyond the cost of Windows copies and support. If they package a commercial distribution where they can always resort to the vendor for complex support situations, the price they pay for that distro is likely to be on par with the deep-discounted OEM Windows copies they install today.
Now if/when the market of users who want Linux over Windows bundled grows significantly, the vendors with Linux preloads enjoy a larger market until everyone else does it and ships more product. There is the incentive for Linux bundling, not strict cost savings.
I like Linux, I use it exclusively for work and home. However I know through my work the challenges that face a company trying to sell supported versions of Linux. Even if it is the greatest thing on Earth, a support contingency is needed for customers to be comfortable.
Well, along with the other responses in the thread, a key phrase in your post is 'a platform that...', meaning a singular environment that manages to attain Windows compatibility. That would still deny users choice and customization.
When you write an application against portable APIs, you give users freedom to choose what platform suits their needs best and run your application. Whenever a platfrom is dictated to the user for the sake of the applications, it is suboptimal. Whether the base is free or Free or whatever, it is still a lack of choice at stake. I write to APIs like wxWidgets and SDL, and my applications a) run on whatevere platform I want without significant porting effort, though more testing effort is needed, b) run at native speeds (unlike the Java approach), and c) fits in with the look and feel of other non-crossplatform apps (also distinct from the Java approach).
-1, Clueless.
That isn't a point of contention, read at *least* the summary before going off the handle. This is not about security updates for the benefit of the pirate end user, but the impact of having pirate end users incapable of getting security updates propogating worms that make the rest of the good community suffer.
On remote-exploit security updates, now that I see this circumstance, I think they should apply no matter what. Now feature enhancements and reliability fixes for the end user, those should be denied. Those fixes not being applied are far more annoying to the typical end user anyway, so MS would improve the community by fixing even the pirate systems in the ways that impact the community, but keep things hard for the pirate users by leaving their system extra buggy (even above and beyond the normal Windows experience).
They *are* talking about a cluster too, not a single system, so the comparison is relevant.
Their claim of one remote hole in the default install is lame, *I* run a platform that has *never* had a remote hole in its default install...DOS!
Slashdot is making a mountain out of this molehill of an announcement. This is simply a different Ethernet Switch Module for a bladecenter chassis. Switch goes bad or becomes antiquated, pull it and replace it. Just means cisco will now provide a switch that conforms to the required form factor and connector. This complements the current D-Link offering (I think their switch is D-Link right now, either that or Nortel, can't remember).
We can't.
Ok, with that out of the range, it isn't so simple as 'just write one'. If that were the case, there are already many many players out there that are technically capable of playing DVDs that could be 'legitimized' (mplayer, xine, ogle come to mind).
However, the MPAA isn't interested in that path. Open Source and MPAA don't mesh. An open development community cannot write a truly closed-source application by definition.
The only path would be a small community to come together, sign NDAs from the get go, never consult existing open source implementation in writing their code, and pay a significant monetary sum to the MPAA for their trouble.
As to a free video format, some exist. .ogg (which can contain video streams, and by convention gets .ogm in such a situation) and matroska are open....
With container formats, I'm not sure any of the major ones are very closed or restricted, but certainly
There are also a few open codecs. The most successful by far would have to be xvid. The Ogg people have picked up a codec from On2 and their version is Theora. There are probably more, but that covers it.
Now the dynamic bitrate idea is cool, and vorbis has it for audio. I don't know of that in any video, Tarkin would've been the best bet, but all mention of it seems to be gone from xiph's site, which likely indicates it just isn't going to happen.