 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The BBC's iPlayer system "works". I mean, it's so horrifyingly blurry
>> that you sometimes can't see people's faces clearly enough to recognise
>> who's who, and often the end credits are unreadable. But technically
>> that still counts as "works", right?
>>
>> I just looked it up. The transfer rate of a DVD is 10.5 mbit/sec. The
>> maximum broadband speed you can get is 8 mbit/sec. So... does that mean
>> that people in America have something faster than ADSL or something?
>
> no, it simply means MP4 does a way better job at compressing than DVD codecs...
> they are watching non-blurry HD streams, real-time.
DVD is MPEG2. (?) I thought nobody had implemented MPEG4 yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 31/01/2012 13:36, Francois Labreque wrote:
> Le 2012-01-31 04:12, Invisible a écrit :
>>
>> I'm saying that if (for example) I read somewhere that a lot of
>> companies use Citrix to host their applications, that doesn't really
>> qualify me for a job managing Citrix. If I had actually /used/ Citrix,
>> or something vaguely like it, then yes. But having read about how it
>> exists and people use it? Not so much, no.
>>
>
> It would allow you to have a better understanding of how that business
> operates. Having a general idea of how entrerpise apps like SAP, BEA
> Weblogic, or Websphere work is never a bad thing
Sure. But (for example) I gather that some people use SAN technology. I
cannot for the life of me begin to imagine why you would accept such a
massive performance hit in exchange for the mere ability to plug and
unplug disks virtually rather than physically. But apparently everybody
is doing it, for reasons unknown.
So in this instance, I know what the world is doing, but I still have
absolutely no insight at all. It hasn't helped.
>>>> OK, I have to ask: What the hell is this "RSS" everybody keeps
>>>> mentioning?
>>>
>>> Google it. If that doesn't work, try "Really Simple Syndication". It's
>>> only all over the web.
>>
>> As usual with Wikipedia, the page babbles about updates and feeds and
>> XML and "syndication" and something about RDF, but utterly fails to
>> explain WHAT IT IS.
>
> This is similar to what news organizations do with newsfeeds from
> Reuters, AP, AFP, etcept it's for the common mortal. It's a standardized
> way to package news items (or in many cases, blog entries). It allows
> you to view content that comes from other sources. Some people use that
> to put "in the news..." sections on their websites, some others use RSS
> readers to gather news flashes and what nots from multiple sources they
> find interesting.
I'm still failing to see why this is in any way "useful". Unless you run
a news website, which I don't.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> "I'm not into Pokeman."
>>
>> Is it bad that I realise it's actually spelt Pokémon?
>
> Not really, they have been mainstream so long that even non-virgins know
> this.
...Is it bad that I own a copy of The Pokémon Trainer's Handbook? o_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 escreveu:
>>> The BBC's iPlayer system "works". I mean, it's so horrifyingly blurry
>>> that you sometimes can't see people's faces clearly enough to recognise
>>> who's who, and often the end credits are unreadable. But technically
>>> that still counts as "works", right?
>>>
>>> I just looked it up. The transfer rate of a DVD is 10.5 mbit/sec. The
>>> maximum broadband speed you can get is 8 mbit/sec. So... does that mean
>>> that people in America have something faster than ADSL or something?
>>
>> no, it simply means MP4 does a way better job at compressing than DVD
>> codecs...
>> they are watching non-blurry HD streams, real-time.
>
> DVD is MPEG2. (?) I thought nobody had implemented MPEG4 yet.
bluray is almost 6 years old already. MP4 is almost already in every
browser as part of HTML5 spec.
see what you get for not reading slashdot feeds? You sound almost like
a caveman!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> no, it simply means MP4 does a way better job at compressing than DVD
>>> codecs...
>>> they are watching non-blurry HD streams, real-time.
>>
>> DVD is MPEG2. (?) I thought nobody had implemented MPEG4 yet.
>
> bluray is almost 6 years old already.
And? I used standard definition video as an example because it has more
modest data rate requirements. If broadband is too slow for standard
definition, it is /obviously/ too slow for HD.
> MP4 is almost already in every browser as part of HTML5 spec.
I also thought nobody has implemented HTML5 yet. (Hell, I thought they
hadn't even finished /specifying/ it yet - not that that ever stopped
anybody. :-P )
> see what you get for not reading slashdot feeds? You sound almost like a
> caveman!
Riiiight. Because if I visited Slashdot everyday I would already know
all these things. Oh, wait...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] dev null> wrote:
> >>> no, it simply means MP4 does a way better job at compressing than DVD
> >>> codecs...
> >>> they are watching non-blurry HD streams, real-time.
> >>
> >> DVD is MPEG2. (?) I thought nobody had implemented MPEG4 yet.
> >
> > bluray is almost 6 years old already.
>
> And? I used standard definition video as an example because it has more
> modest data rate requirements. If broadband is too slow for standard
> definition, it is /obviously/ too slow for HD.
>
> > MP4 is almost already in every browser as part of HTML5 spec.
>
> I also thought nobody has implemented HTML5 yet. (Hell, I thought they
> hadn't even finished /specifying/ it yet - not that that ever stopped
> anybody. :-P )
>
> > see what you get for not reading slashdot feeds? You sound almost like a
> > caveman!
>
> Riiiight. Because if I visited Slashdot everyday I would already know
> all these things. Oh, wait...
"oh, wait! I know nothing, I want to know nothing and I'm actually trying to
argue with people who know it better."
I don't think you're dumb actually. I think you're a very skilled
attention-whore troll.
I don't time or fun any more for this BS routine...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 1/31/2012 12:52 PM, Orchid Win7 v1 wrote:
>>> As usual with Wikipedia, the page babbles about updates and feeds and
>>> XML and "syndication" and something about RDF, but utterly fails to
>>> explain WHAT IT IS.
>>
>> This is similar to what news organizations do with newsfeeds from
>> Reuters, AP, AFP, etcept it's for the common mortal. It's a standardized
>> way to package news items (or in many cases, blog entries). It allows
>> you to view content that comes from other sources. Some people use that
>> to put "in the news..." sections on their websites, some others use RSS
>> readers to gather news flashes and what nots from multiple sources they
>> find interesting.
>
> I'm still failing to see why this is in any way "useful". Unless you run
> a news website, which I don't.
Its also used by blogs, and the like, in which case, instead of going to
the blog, you might get the text, and links, packaged differently, for
use in something like a cell phone app. Or, for example, you might have
something like here, where comments are collected, into a single
package, and "filed" along with the original item, sort of like news
readers do with threads.
Basically, its a way of delivering content automatically, to clients
that support it, by "subscribing", the same way you tell a news reader
that you want to get everything sent to povray.off-topic when you log in
to the server, rather than having to go to every single website you want
to read them from.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-01-31 14:52, Orchid Win7 v1 a écrit :
> On 31/01/2012 13:36, Francois Labreque wrote:
>> Le 2012-01-31 04:12, Invisible a écrit :
>>>
>>> I'm saying that if (for example) I read somewhere that a lot of
>>> companies use Citrix to host their applications, that doesn't really
>>> qualify me for a job managing Citrix. If I had actually /used/ Citrix,
>>> or something vaguely like it, then yes. But having read about how it
>>> exists and people use it? Not so much, no.
>>>
>>
>> It would allow you to have a better understanding of how that business
>> operates. Having a general idea of how entrerpise apps like SAP, BEA
>> Weblogic, or Websphere work is never a bad thing
>
> Sure. But (for example) I gather that some people use SAN technology. I
> cannot for the life of me begin to imagine why you would accept such a
> massive performance hit in exchange for the mere ability to plug and
> unplug disks virtually rather than physically. But apparently everybody
> is doing it, for reasons unknown.
>
The big advantage to adding disks virtually instead of physically is
that you are not limited by the form factor of the server, the power
output of the PSUs and most importantly, they can be done on the fly,
without having to take an outage.
In your environment, it may not be that big of an issue, but when you
have contracted service level agreements that you will have 99.99%
uptime, you have no other choice. Do the math, that means 1m42s of
downtime per month... try powering off a server, taking it out of the
rack, adding a disk and powering it back on in less than 10 times that!
We've also had the performance discussion before. Yes, the theoretical
access speed of a local SATA drive is much faster than that of a SAN
attached logical disk, but in actual real world practice, with real
world data, there's not much of a difference, even on SANs located
halfway across town in another building.
Which brings us to the last big advantage of SANs. Instant disaster
recovery! Your main office is now a pile of smoldering ruins? No
biggie, just reassing the LUNs from that offsite SAN to another machine
at the business continuity location and power it up, and presto! your
business is back on its feet.
sometimes, taking a small performance hit on each I/O operation is
nothing compared to being able to get the company back up and running
even though a hurricane decided to pay your data centre a visit.
> So in this instance, I know what the world is doing, but I still have
> absolutely no insight at all. It hasn't helped.
>
That's because you keep forgetting that other people may have other
needs than yours. Reading about technology often includes case studies.
From those, you'll learn that the needs of the petrochemical industry
are very different than those of the financial industry, the online
services industry or that of hospitals, for example.
>>>>> OK, I have to ask: What the hell is this "RSS" everybody keeps
>>>>> mentioning?
>>>>
>>>> Google it. If that doesn't work, try "Really Simple Syndication". It's
>>>> only all over the web.
>>>
>>> As usual with Wikipedia, the page babbles about updates and feeds and
>>> XML and "syndication" and something about RDF, but utterly fails to
>>> explain WHAT IT IS.
>>
>> This is similar to what news organizations do with newsfeeds from
>> Reuters, AP, AFP, etcept it's for the common mortal. It's a standardized
>> way to package news items (or in many cases, blog entries). It allows
>> you to view content that comes from other sources. Some people use that
>> to put "in the news..." sections on their websites, some others use RSS
>> readers to gather news flashes and what nots from multiple sources they
>> find interesting.
>
> I'm still failing to see why this is in any way "useful". Unless you run
> a news website, which I don't.
It is also very useful for people who READ news websites as you can
configure an RSS reader to pick up those feeds that interest you and get
the news you want in Thunderbird, for example, instead of having to read
half a dozen different web sites every morning, while your coffee brews.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Having a general idea of how entrerpise apps like SAP, BEA
>>> Weblogic, or Websphere work is never a bad thing
>>
>> Sure. But (for example) I gather that some people use SAN technology. I
>> cannot for the life of me begin to imagine why you would accept such a
>> massive performance hit in exchange for the mere ability to plug and
>> unplug disks virtually rather than physically. But apparently everybody
>> is doing it, for reasons unknown.
>
> The big advantage to adding disks virtually instead of physically is
> that you are not limited by the form factor of the server, the power
> output of the PSUs and most importantly, they can be done on the fly,
> without having to take an outage.
But you still need to (at a minimum) reboot the server after you change
the SAN mapping anyway.
> In your environment, it may not be that big of an issue, but when you
> have contracted service level agreements that you will have 99.99%
> uptime, you have no other choice. Do the math, that means 1m42s of
> downtime per month... try powering off a server, taking it out of the
> rack, adding a disk and powering it back on in less than 10 times that!
Uhuh. And when one server physically dies, it's going to be down a tad
longer than 1m42s. So if you don't have the spare capacity to handle
that, a SAN still hasn't solved your problem.
> We've also had the performance discussion before. Yes, the theoretical
> access speed of a local SATA drive is much faster than that of a SAN
> attached logical disk, but in actual real world practice, with real
> world data, there's not much of a difference, even on SANs located
> halfway across town in another building.
This makes no sense at all. How the hell can a 6 Gbit/s SATA link
perform the same as a 100 Mbit/sec Ethernet link? Never mind a 10
Mbit/sec Internet link. That makes no sense at all. (Unless your actual
disks are so feeble that all of them combined deliver less than 10
Mbit/sec of data transfer speed...)
> Which brings us to the last big advantage of SANs. Instant disaster
> recovery! Your main office is now a pile of smoldering ruins? No biggie,
> just reassing the LUNs from that offsite SAN to another machine at the
> business continuity location and power it up, and presto! your business
> is back on its feet.
>
> sometimes, taking a small performance hit on each I/O operation is
> nothing compared to being able to get the company back up and running
> even though a hurricane decided to pay your data centre a visit.
That works if a hurricane takes out the data centre with your SAN in it.
Not so much if it takes out the data centre with your compute devices in
it. :-P
For that, you would need [at least] two geographically remote sites
which duplicate everything - disk and other hardware as well. I'm
struggling to think of a situation where the volume of data produced per
hour is so low that you can actually keep it synchronised over the
Internet. And if it isn't in sync, then a failover to from primary to
secondary system entails data loss.
>> So in this instance, I know what the world is doing, but I still have
>> absolutely no insight at all. It hasn't helped.
>
> That's because you keep forgetting that other people may have other
> needs than yours.
Perhaps. But saying "we work in the financial industry" doesn't tell me
how your needs are different than mine. Really, the only way you'd truly
come to understand this is by actually /working/ in that industry. And
that's just not possible.
>> I'm still failing to see why this is in any way "useful". Unless you run
>> a news website, which I don't.
>
> It is also very useful for people who READ news websites as you can
> configure an RSS reader to pick up those feeds that interest you and get
> the news you want in Thunderbird, for example, instead of having to read
> half a dozen different web sites every morning, while your coffee brews.
Right. So it's a way to track what's new on multiple sites simultaneously?
If that's all it is, why didn't somebody just *say* so?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-02-01 09:03, Invisible a écrit :
>>>> Having a general idea of how entrerpise apps like SAP, BEA
>>>> Weblogic, or Websphere work is never a bad thing
>>>
>>> Sure. But (for example) I gather that some people use SAN technology. I
>>> cannot for the life of me begin to imagine why you would accept such a
>>> massive performance hit in exchange for the mere ability to plug and
>>> unplug disks virtually rather than physically. But apparently everybody
>>> is doing it, for reasons unknown.
>>
>> The big advantage to adding disks virtually instead of physically is
>> that you are not limited by the form factor of the server, the power
>> output of the PSUs and most importantly, they can be done on the fly,
>> without having to take an outage.
>
> But you still need to (at a minimum) reboot the server after you change
> the SAN mapping anyway.
>
No. Do you need to reboot after swapping a CD or a usb key? OSes have
been able to handle adding and removing storage space for a while, now.
Obviously, Windows may complain if you try to pull the C: drive from
under its feet, but you shouldn't actually boot from a SAN drive under
normal circumstances anyway.
I'm no Windows Server expert, so I don't know if it allows you to extend
disk space on the fly, but I do know that many flavors of Unix do allow it.
>> In your environment, it may not be that big of an issue, but when you
>> have contracted service level agreements that you will have 99.99%
>> uptime, you have no other choice. Do the math, that means 1m42s of
>> downtime per month... try powering off a server, taking it out of the
>> rack, adding a disk and powering it back on in less than 10 times that!
>
> Uhuh. And when one server physically dies, it's going to be down a tad
> longer than 1m42s. So if you don't have the spare capacity to handle
> that, a SAN still hasn't solved your problem.
>
Need help moving those goalposts? They look heavy! We weren't talking
about a server dying. We were talking about needing mroe disk space. A
SAN is not the remedy to all problem, obviously. Just like having
onsite generators can help you avoid power outages, but as we saw last
March, they aren't necessarily very helpful if a tsunami took the fuel
tanks away.
>> We've also had the performance discussion before. Yes, the theoretical
>> access speed of a local SATA drive is much faster than that of a SAN
>> attached logical disk, but in actual real world practice, with real
>> world data, there's not much of a difference, even on SANs located
>> halfway across town in another building.
>
> This makes no sense at all. How the hell can a 6 Gbit/s SATA link
> perform the same as a 100 Mbit/sec Ethernet link? Never mind a 10
> Mbit/sec Internet link. That makes no sense at all. (Unless your actual
> disks are so feeble that all of them combined deliver less than 10
> Mbit/sec of data transfer speed...)
>
You're making a strawman argument. No one ever said that SANs run over
10Mbit ethernet. While it is possible to use iSCSI on a 10 or 100 Mbps
ehternet lan, most SAN implementations run dedicated protocols over
fibre at Gbps speeds.
Last time we went over this, I pointed you to studies that showed that
over millions of "real-life" I/O operations, the SAN was performing no
worse than locally-connected disks.
See for example:
http://www.sqlteam.com/article/which-is-faster-san-or-directly-attached-storage
>> Which brings us to the last big advantage of SANs. Instant disaster
>> recovery! Your main office is now a pile of smoldering ruins? No biggie,
>> just reassing the LUNs from that offsite SAN to another machine at the
>> business continuity location and power it up, and presto! your business
>> is back on its feet.
>>
>> sometimes, taking a small performance hit on each I/O operation is
>> nothing compared to being able to get the company back up and running
>> even though a hurricane decided to pay your data centre a visit.
>
> That works if a hurricane takes out the data centre with your SAN in it.
> Not so much if it takes out the data centre with your compute devices in
> it. :-P
>
Most businesses will invest in redundant servers BEFORE investing in
redundant facilities, therefore, if you have more than one data centre
with redundand SANs, you more than likely built your business continuity
plan so that you also have enough CPUs avaialble at both sites to run
your entire operation from just one of those sites, and you probably run
monthly or quarterly disaster drills to make sure that your plan
actually works.
Four 9s and Five 9s uptime is expensive.
> For that, you would need [at least] two geographically remote sites
> which duplicate everything - disk and other hardware as well. I'm
> struggling to think of a situation where the volume of data produced per
> hour is so low that you can actually keep it synchronised over the
> Internet. And if it isn't in sync, then a failover to from primary to
> secondary system entails data loss.
>
Not the Internet, multiple dedicated 10Gbps DWDM links. You'd be
surprised to know that most Fortune 1000 entreprises actually do this
already.
All entreprise database systems (Oracle, DB2, MS-SQL, et al.) allow for
the real-time duplication of the data across multiple tables, so it's
easy to tell your DBMS to write to table 1 on disk E: and to table 2 on
disk F:, and to map those disks to LUNs that are on different physical
SANs. Most SANs can also handle this internally without the server OS
knowing anything about it, just like RAID is transparent to the OS and
applications.
>>> So in this instance, I know what the world is doing, but I still have
>>> absolutely no insight at all. It hasn't helped.
>>
>> That's because you keep forgetting that other people may have other
>> needs than yours.
>
> Perhaps. But saying "we work in the financial industry" doesn't tell me
> how your needs are different than mine. Really, the only way you'd truly
> come to understand this is by actually /working/ in that industry. And
> that's just not possible.
>
Are you saying it's impossible to work in the banking industry? Or are
you saying that the banking industry is so secretive about their work
that you can't even find out how they operate without working there?
Google "Tandem computers". Their story is very well known and was
instrumental to the rise of computers in the financial world. There's
no need to be working at a bank to find out about that. Look at the job
offers for a big bank. If, for example, they're looking for someone
with Solaris and Oracle knowledge and "experience with high-availablilty
is an asset" that should tell you enough about the products used at the
bank in question, and if you're interested to know more about how
Solaris and Oracle handle HA, you can simply go to their web site, read
white papers, Gartner studies, etc...
Of course, you can also decide that it's not worth it to learn about
these things and simply shrug it off, but don't complain that you can't
get jobs outside of the little hole you dug yourself into.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
