MakeMKV decrypts the source, de-muxes the selected streams, and re-muxes them into a single MKV file. No transcoding. It will alter the video stream (generally by dropping frames) so that it stays in sync with audio tracks. This is typically active on titles that use seamless branching and contain overlapping video timestamps at branch transitions.
I maintain an optical subscription to Netflix solely because a lot of major titles just aren't available for streaming. I rip BR disks via MakeMKV and send 'em back. I shove them through Handbrake to make them all nice for playback to my various endpoints, copy the resulting MKVs to a NAS, and serve them via Plex to wireless Rokus. When I'm done watching, I delete the title.
Been in this mode for quite a while. Video, audio, and subtitles are not a problem. The only thing I had to find out the hard way was that Roku devices will just not reliably handle passthrough DTS-HD/MA audio tracks, so you're stuck with plain DTS as the highest fidelity sound.
Your comment completely disregards the benefits of the social and emotional learning done in college. Also known as making friends (with a diverse set of people) and getting laid.
And none of this happens in the workplace? I beg to differ... apart from the getting laid part, perhaps. Dunno what your company policy is like.
It also assumes that someone working as an IT monkey will spend free time learning but that someone in college won't.
No, it assumes that both will continue to learn on their own, and thus end up at about par for the time spent. The experience may differ between the practical and theoretical, the mechanics and the concepts. I am assuming a self-motivated, intelligent individual in both cases. But my point isn't that one is better than the other, but that a degree is not necessary to be successful in the field, contrary to the previous poster.
As a blanket statement? For the IT field? Bullshit.
You can be very successful in technology with no degree whatsoever. You just have to be willing to put in the time and the work yourself.
If you're computer literate, can write basic code, have a reasonably broad exposure to different OS and hardware platforms (enthusiastic hobbiest), you can get an entry-level job. You'll spend the four years that you would have spent in college in the field, doing grunt work. At the end of that time, chances are good that you and the recent college grad may be competing for the same jobs. They'll have skipped the cable-monkey/printer-minder stage, and you'll have skipped out on OS theory. However, you as an enthusiast are probably hanging out in the same community of user groups and nerds that they are, and that's where a lot of the real practical learning is - in the sharing of new information amongst peers, not the dictation of established doctrine in the classroom.
The hard part for the non-degreed is establishing credentials, and it's all up to you to do that. Your degree is a certification that you're (supposedly) not an idiot, and it's tangible. As someone without that piece of paper, you have to establish that cred yourself - by contributing to FOSS projects, writing your own tools, getting your name known in the community. I'm more likely to hire the guy with no degree and five OSS projects to his name than someone with a freshly minted BS in comp-sci, to be honest.
I've no degree - all my credentials come from my body of work, professional network and peers. I did my time as a field tech, parlayed my experience with my hobby pursuits into a systems management job, learned all I could in the process, then moved into systems analysis and engineering, picking up skills as needed on the fly. Now, I'm sitting nicely in a position with a solid six-figure salary and 17 years of an established reputation backing me up.
A BS is an ante into the game, but after that both the academic and the street-smart have to play their cards well to advance.
I'm going to go all terminology-pedant on you, because I've been hearing the wingnut teabaggers misuse "communist", "socialist", and "fascist" for a while now as fear words.
Communism is a *socioeconomic* philosophy, where property is held in common, particularly means of production, with common access to means of consumption. It has nothing to do with quantity or quality of government regulation.
Totalitarianism is a *political* philosophy where the state recognizes no bounds to its power to control the actions and lives of its citizens/subjects.
Many Communist countries also had Totalitarian governments, because unless you have a very small, commonly-aligned populace, everyone must be forced to participate in a communist system for it to function as intended. However, you can have one without the other.
The link you provide speaks to the problems of bit-packing on the symbol states, and the solution of Trellis Modulation, which I mentioned. Trellis coding allowed for packing more than 4 bits to each symbol without increasing the error rate, leading to the development of the v.32bis standard and 14.4Kbps modems. Which is what I said - it wasn't high baud rates, but better bit packing that realized faster speeds.
And you're still saying "baud" when you mean "bits per second".
The "baud rate" of telephone lines is pretty slow. Baud rate is the number of symbol transitions per second the media can support. Baud rate and bits/second have not been equivalent since Bell103a/V.21 frequency-shift-keyed modems, where 300 baud meant 300 bps, each state transition being a discrete tone that indicated a "mark" or "space" (0/1). From then on, Bell 212a/V.22 used phase-shift keying to get 1200 bps out of a 600 BAUD symbol rate, encoding two bits of information per symbol.
POTS lines are pretty pokey - the practical maximum BAUD rate is less than 3500 symbols/sec. Where speed advancements were made in later evolutions of POTS modems were in the number of bits that could be encoded per symbol, using QAM and Trellis Modulation. A 33.6 kbps modem is encoding 10 bits per symbol onto a 3429 baud carrier.
So, when you kept hearing "phone lines max out at less than 4800 baud", that was correct. The engineers kept wringing higher bit rates out of narrow-band POTS by putting more information on each of the symbols transmitted.
Then, with V.70 and V.90, the modulation schemes took advantage of certain characteristics of non-muxed POTS lines to use PCM digital encoding instead of an analog audio carrier. Unfortunately, if you were serviced through a SLC-96 ("Slick") muxed subscriber loop, which multiplexed the signal from your subscriber line to the central office, you could only connect with older analog modulation schemes such as v.32/v.32bis/v.34.
Don't want to reduce your smug, but we're doing just this - restart services from the failed component, service the failed resource on a non-critical timeframe. The small shop with a half-dozen server boxes doesn't give a damn about cooling costs or this level of service, for the most part. If they do, they're likely going to someone else to satisfy that requirement, not doing it in house.
I've got stack of servers in my datacenter that are allocatable on demand. Any unused server blade is a potential spare. If a production blade tips over with a CPU fault, memory error, or similar crash, its personality (FC WWN's, MAC's, boot and data volumes, etc.) are moved to another blade and powered on through an automated process. Since the OS and apps live on the SAN, both VMs and dedicated server hardware can be abstracted away from the actual services they provide.
This is a product my company's selling to the market at large right now, and that I designed. Any of our IaaS customers can take advantage of the redundancy and fault tolerance built into the system. Even the six-server small IT shop.
Even then, a small IT organization can easily virtualize and provide some level of HA services in hypervisor clusters now. It's just not that hard anymore. Take the handful of servers you're running on now, replace them with an equal number of nodes in a VMM cluster, and go to town. Any of those systems fails, shift the load to the other nodes and effect repairs.
"Cloud computing," while it has very nearly achieved meaningless buzzword status, is an attempt by the business and marketing types to get their heads around what is a very real evolutionary transformation occurring in IT. The drivers are the drying up of CapEx budgets, the need to reduce service delivery time, and the requirement to purchase and pay for only what an organization needs to fulfill their business requirements.
Capital expenditures are coming under increased scrutiny, and are under constant budgetary pressure. "Cloud" based, on demand services allow IT service procurers to shift from a CapEx based model of owning the infrastructure to an OpEx model. Operational expenditures are typically larger chunks of budget than capital purchases, and moving IT services there can allow them to get "lost in the noise". Less red tape, less stringent approval processes, etc.
Time to deliver service is a labor cost, and if a procurer can shift that operational expense from internal overhead required to deploy an IT architecture to acquiring those same services from a cloud provider, it's perceived as a big win. The provider gets to deal with the headaches of capacity management, infrastructure design and integration, and delivering IT resources. The purchaser gets the luxury of simply specifying how much they want, for how long, and letting the provider leverage its economies of scale and automated processes to deliver the resources within the terms of the provider's SLA. The tradeoff is that the consumer of cloud services loses the ability to specify the platform and all its parameters in exchange for rapid delivery of a standardized service.
IT organizations are also under increased pressure to abandon the concept of designing and purchasing for peak capacity. Cloud providers are specifically addressing these needs by allowing their customers to pay only for what they use, not the spare capacity. Since the "cloud" capacity is shared, reused, and managed by the provider, the customer is afforded the ability to scale their environment dynamically to meet the needs of the business and its budget.
Now, how this ties into Web Services is important. Web Services, for a long time, was a solution in search of a well-defined problem. Now, with the "cloud" becoming a workable construct, Web Services come to the forefront as the way that stateless platforms can interact without intimate knowledge of the underlying infrastructure. Web Services will become more and more important as IT services are increasingly abstracted away from the hardware and OS platform. As I've worked for the past two years as a design architect for an infrastructure-as-a-service type platform, I can say with some authority that they're are an integral part of how we're going to need to deal with virtualized environments and stateless service contexts as they become pervasive elements of IT solutions.
Recruiting agencies will put everything and anything on a candidate's resume. Their people are evaluated by how many interviews they can schedule, and how many placements they achieve. So, they will stack the applicant's CV with anything that's ever been in the same 10-mile radius as the individual in question.
The result is that you're faced with a piece of paper that looks identical to every other programmer's. It's an alphabet soup -.NET, C#, Java, C, C++, Python,.NET, ASP, ADO, JDBC, XSLT, VB, XML, SQL, BLAHBLAHBLAH. And every programmer lists every one of these. Even the projects look the same - "Senior programmer for web development project implementing a user portal and reporting system for... etc, etc, etc." I have a stack of 12 resumes sitting here in front of me, and could literally swap the names in the header and you wouldn't be able to tell the difference.
So, we make a first pass, weeding out those who a) can't write, even after the headhunter has spiffied their CV, b) are scant with details, and c) hop assignments every three months. The rest have to do a preliminary interview, and that mainly consists of determining whether or not they actually know any of the stuff that their resume's been padded with. Sure, we ask the traditional interview questions, but we also do a base knowledge test. You would be surprised how many.NET "programmers" we get who don't know the most basic C# operations, web developers who don't know the difference between POSTing and GETting form data, and "7+ years experience SQL" applicants who can't tell you how a left outer join works.
Programmer's resumes are becoming increasingly useless, especially when you're flooded with nearly identical H1-B applicants with the same vague academic credentials (ie: "BS Elec. Eng., India", "Masters of Computer Applications" - no institution listed, "Bachelor of Engineering" - no discipline given), identical alphabet soup, and interchangeable litanies of 6-month contracts scattered about the country. They all have widely varying levels of competence that is in no way obvious from their resume. They all have "7+ years experience." That's what makes up 90% of the programmer pool these days, and even if you're in the top 10% with verifiable credentials and a real track record, you're gonna have to go through the same process. Because those of us on the hiring end can't tell anymore from your paperwork, without giving you some sort of objective evaluation of skills, syntax, and basic concepts.
It's been the rule for some time now. Ten years ago, it was all of the newly minted MCSEs rolling out of the fly-by-night tech schools. Before that, it was the "paper CNA/CNE's" who were able to sit the Netware exams and pass by the grace of their deity of choice. And there have always been the code-monkey grindhouse diploma-mill shops, who crank out "programmers" in the language du jour - especially since the web boom - CGI, Java,.NET, AJAX. All with credentials like "Doctor of Divine Coding" and the real competency of an ADD third-grader.
So, don't take it as a personal insult. You may be better than all of the above, but no one can determine that from a piece of paper, a firm handshake, and a good story about how you were the lead coding god on your last project. 'Cause there's a dozen other applicants out there with the same spiel.
By no means was the PC20-III (bollixed the model# the first time 'round) a particularly stellar box - never claimed that it was. It was just a successor to my old caffe-brown C-64 (with a breakout box ribbon cable soldered to the modem port for the 1670, and a stereo-SID mod). Not nearly as expensive as a Compaq or IBM toaster, and better than the Leading Edge dreck that was targeted to the consumer market. However, it was still a PC-clone, but that's what I needed at the time.
The Amiga, as swell a design as it might have been, was too expensive to be a gamer (like the C64/128) and too outside the mainstream to be a viable competitor to the PC or Mac. And for almost two decades now, the Amiga fanboys have been wistfully stroking themselves to fond memories of Guru Meditations to realize that it was an overly complex design that was a business nightmare for its creators. Too expensive to build, too expensive to sell, margins sliced to the bone to make them "affordable."
Visionary, we can debate, but absolute crap business sense. The only mid-to-long-term good that came out of the Amiga project was Ensoniq. The ESQ-1, SQ-80 and VFX-SD did more to change the synth world than the Amiga did to revolutionize personal computing.
It's tragic the same brand used by excellent and original personal computers like the PET, VIC-20, C-64 and Amiga is now glued to x86 computers that still have some form of an ISA bus inside its chipset and whose processor still wakes up thinking it's an 8088 inside a IBM 5150 PC.
Sorry to break this to you, but even back when Commodore was still really Commodore, still selling the Amiga, way back there in the late 80's, they were also selling x86 boxen.
My first PC clone was (ghod help me) a Commodore PCIII-20, an 8088 machine (I later replaced the iNTEL chip with an NEC V-20) with 640K of RAM and an MFM HD-controller off of which hung a Seagate ST-225. CGA/Hercules mono on the motherboard! W00T! My original BBS ran on that box until I could replace it with a home-built 80286 machine (at a whopping 12MHz) with 1MB on the mboard and an AST Advantage/2 card for disk cache and external modem ports.
So, that brand's been long-sullied, almost 20 years ago, with PC-clone "blandness". Showrooms used to market the 68K-based Amigas and the PCs right next to each other.
You mean I can get 1980's "Midnight Madness", the cinematic master piece debut of one Mr. Michael J. Fox, in HD? All 23 times a week? Iron Eagle III? Bad 80's and 90's soft-core, too? The same "blockbuster" bombs over and over every night for a month, at a premium price? Tell me more! Ooo! Ooo! Miami Vice in HD! Omygodomygodomygodomygod...:faints:
I've replaced all the outside lighting and the utility lighting in the basement with CFLs. All in all, I've replaced 700W of incandescents with 137W of fluorescent. They're much brighter, faster to come to full output, and purer white than any compact fluorescent bulb from the last generation.
They're absolutely perfect for work and utility areas. For living areas and reading light, however, I still prefer tungsten bulbs.
Well, I think the objection is more to those that call their wives (or whoever) in the grocery and stand there, oblivious to the world around them, as they block aisles and access to other shoppers while they blab away. Then, there's the just plain rudeness of having a high-volume, personal conversation in the middle of a public venue.
Standing off to the side, out of the way of the rest of the shoppers, and placing a quick call to find out what you can substitute for the crimini mushrooms that the store's out of? Great - go to it.
Standing in the middle of a busy aisle, babbling on about your plans for the weekend while everyone has to work around you? Having a profanity-laced argument in the checkout line? Being one of those nimrods that yammers on in their "outdoor voice" into one of those god-forsaken bluetooth earpieces as they wait at the deli, so that the guy behind the counter has to hold up service to interrupt you to find out how much olive loaf you want? Frackin' annoying as all hell.
Most people just don't get "courtesy first, your own amusement and/or gratification second." It's the nice little things that grease the wheels of polite society.
What these guys are doing is not compression. It's commonality factoring. No piece of data is ever stored more than once. Typically, this is done by a hashing algorithm that starts at a high level and indexes everything down to a discrete block size of a few K.
Each block gets an index checksum, then each file, each subdirectory, each parent directory, and so forth until the entire disk volume has a cumulative hash. Then, it's very easy to determine a) what has changed (and where), and b) what has been seen before.
When a backup starts, the client compares the volume hash signature to that on the backup system. If it matches - nothing has changed. Backup over. If it doesn't, then you walk the indexes to find out exactly what has changed, and then only prepare to send those dirs, files, or discrete blocks - whatever's the smalles object that expresses the delta. When those objects are queued to send to the repository, the client first generates a hash of the object and asks the repository if it's seen it before. If not, it sends the index and the data. If so, it sends nothing, since the repository's already got that particular chunk stored somewhere. There's some re-hashing and index reverification on the other end to make sure that all is consistent.
Therefore, each backup appears a "full" backup, not a file-level diff, since the entire image is comprised of a map of every object in the volume. In reality, each backup is a set of pointers into a hashed data store (commonly called a CAS, or Content Addressed Store) from which is is reconsitituted as needed.
Having tested and deployed one of these types of systems, I can say that a) it's great for desktops, where most of the data between boxes is identical - the OS, the core apps, etc, and only the user data and localization is different, and b) it's awful for pre-compressed data like streaming audio, video, JPEGs, PDFs, etc. Since compressed data is entropic data, there can be no commonality within the file or versions of it, unless the file itself is identical and present from multiple sources. Change one byte of a file and recompress it, and all the blocks are unique.
However, this is not new. Giggle Avamar Technologies and Arsenal Digital. BTW - this tech is pretty good for remote backups over low-bandwidth links, since it vastly reduces the amount of data that needs to traverse the wire.
Aircraft that are rated for ILS Cat-IIIa/b/c approaches can autoland with flare and rollout. The only thing that the pilot needs to do is pull the throttles over the numbers, and the plane will flare, settle to the runway, and rollout with autobraking (provided that brakes are armed). Cat-IIIc approaches are zero/zero - no decision height and down to zero visibility.
A Cat-III-rated aircraft has multiple, redundant autopilots, at least two of which must be functional and locked in to autoland. There are crosswind limitations, but your example (30KTS at 35 from centerline) is a headwind component of 24KTS and 17KTS crosswind component, both of which are within (for instance) the Cat-III autoland restrictions for the 747 (25KT headwind, 25KT crosswind).
In short, they suck, because the industry sucks. They have to offer DRM to appease the suits.
I don't quite understand why everyone gets all up in Apple's shizznit about FairPlay. You do realize that once you have the FP-protected track on your machine, you can burn it to CD. Then, you can rip that track right back off your shiny new CD-R into whatever format you so choose, 100% DRM-free.
So yes, Apple supplies tracks that are DRM-protected. And even though we all know that all DRM schemes are the tool of Satan and his minions, at least Apple, ITMS, and FairPlay allow you to fairly freely media-shift that content. I know it's heretical to suggest to the/. crowd, but to me this seems like a pretty even balance. You can't just redistribute the AAC files, but by a trivial jump through the CD-R hoop, you can play ITMS content pretty much anywhere.
As to another point you made, if your software is telling you what to listen to, and you're obeying it, I somehow don't think that's Apple's fault.
It's not the reflective layer that degrades, but the organic dye that is used. All dyes degrade with age. The metal layer they're sandwiched with is mostly irrelevant.
For fixed lens digitals it probably makes more sense to think about the reproduction ratio in a print made at a standard resolution like 300 dpi.
Ah, but then your "macro" definition shifts dependent on the resolution of your sensor, not the size. You see, the reason that everyone's all catty-wumpus about this terminology is precisely because of the mixing in of elements of cropping, enlarging for prints, and so forth outside of the effect of the lens itself. I prefer to hold to the 1:1 reproduction ratio as the standard, from which you capture an image at various crop factors and resolutions. It's a definition that holds up no matter what the capture media, size, resolution, or method.
1:1 is not an arbitrary value - it is the intrinsic definition of the term "macro." Life-size or larger - the image formed on the focal plane of the lens must be at least as large as the object being represented. Whether a CCD sensor or a piece of film is placed at that focal plane is irrelevant.
If you photograph a 1/2" square, that it fills 1/80th of a 4x5" film sheet, 1/20th of a 6x6 medium format frame, about a fifth of a 35mm frame, or a little over half of a digital sensor makes no difference so long as the size of the projected image is also 1/2" or larger. You're confusing image size with cropping (which isn't something new that came along with digital cameras). Your assertion that "it's the results that count" is the exact same logic that produces a marketing-speak "macro zoom" with a 1:6 reproduction factor and a minimum focusing distance of three feet. As long as you can crop and produce a life-size enlargement, it doesn't matter? Sorry - not so. Go shoot a real 1:1 macro lens with a digital camera and then enlarge a crop of the same subject shot with a "macro zoom" kit lens to an identical size. Then get back to me about that "arbitrary value."
Focusing distance is not sufficient to qualify a lens as a macro. There are close focusing lenses that are not macro, and there are macro lenses with long focal lengths that don't focus particularly close.
A true "macro" lens is defined as a lens that allows for at least 1:1 reproduction of the subject image on the recording media. For the sake of simplicity, we'll talk film. If you photograph an object that is 1/2" across, and the resulting recorded image on the film is also 1/2" in size, you're shooting macro. A "macro lens" is one that is capable of rendering at least this 1:1 reproduction.
Unfortunately, many camera/lens manufacturer have abused the term to mean "focuses at a (slightly) closer distance than a normal lens at an identical focal length, so that when printed to standard 4x6 the image is life-size." This, of course, is regardless of the reproduction ratio of the lens. A rather silly definition, really, since any reasonable frame at any magnification can be cropped and enlarged to "life size" up to a point before quality degrades enough to become unworkable.
Amazon's camera sales are mostly fulfilled through Calumet or Adorama, and are dependent on them for delivery estimates. Adorama tends to close for extended periods to observe Jewish holidays (forget ordering anything from a NY camera store during late-September to mid-October, for instance). They source a few consumer-level products from electronics vendors.
However, if you order something sourced from Adorama during Sukkot - you're waiting a week before anyone even thinks about pulling it off the shelf.
Slashdot Mirror
MakeMKV decrypts the source, de-muxes the selected streams, and re-muxes them into a single MKV file. No transcoding. It will alter the video stream (generally by dropping frames) so that it stays in sync with audio tracks. This is typically active on titles that use seamless branching and contain overlapping video timestamps at branch transitions.
I maintain an optical subscription to Netflix solely because a lot of major titles just aren't available for streaming. I rip BR disks via MakeMKV and send 'em back. I shove them through Handbrake to make them all nice for playback to my various endpoints, copy the resulting MKVs to a NAS, and serve them via Plex to wireless Rokus. When I'm done watching, I delete the title.
Been in this mode for quite a while. Video, audio, and subtitles are not a problem. The only thing I had to find out the hard way was that Roku devices will just not reliably handle passthrough DTS-HD/MA audio tracks, so you're stuck with plain DTS as the highest fidelity sound.
You mean the arm of Alcatel-Lucent that decided they will no longer do pure science, and concentrate on product-oriented R&D?
Your comment completely disregards the benefits of the social and emotional learning done in college. Also known as making friends (with a diverse set of people) and getting laid.
And none of this happens in the workplace? I beg to differ... apart from the getting laid part, perhaps. Dunno what your company policy is like.
It also assumes that someone working as an IT monkey will spend free time learning but that someone in college won't.
No, it assumes that both will continue to learn on their own, and thus end up at about par for the time spent. The experience may differ between the practical and theoretical, the mechanics and the concepts. I am assuming a self-motivated, intelligent individual in both cases. But my point isn't that one is better than the other, but that a degree is not necessary to be successful in the field, contrary to the previous poster.
As a blanket statement? For the IT field? Bullshit.
You can be very successful in technology with no degree whatsoever. You just have to be willing to put in the time and the work yourself.
If you're computer literate, can write basic code, have a reasonably broad exposure to different OS and hardware platforms (enthusiastic hobbiest), you can get an entry-level job. You'll spend the four years that you would have spent in college in the field, doing grunt work. At the end of that time, chances are good that you and the recent college grad may be competing for the same jobs. They'll have skipped the cable-monkey/printer-minder stage, and you'll have skipped out on OS theory. However, you as an enthusiast are probably hanging out in the same community of user groups and nerds that they are, and that's where a lot of the real practical learning is - in the sharing of new information amongst peers, not the dictation of established doctrine in the classroom.
The hard part for the non-degreed is establishing credentials, and it's all up to you to do that. Your degree is a certification that you're (supposedly) not an idiot, and it's tangible. As someone without that piece of paper, you have to establish that cred yourself - by contributing to FOSS projects, writing your own tools, getting your name known in the community. I'm more likely to hire the guy with no degree and five OSS projects to his name than someone with a freshly minted BS in comp-sci, to be honest.
I've no degree - all my credentials come from my body of work, professional network and peers. I did my time as a field tech, parlayed my experience with my hobby pursuits into a systems management job, learned all I could in the process, then moved into systems analysis and engineering, picking up skills as needed on the fly. Now, I'm sitting nicely in a position with a solid six-figure salary and 17 years of an established reputation backing me up.
A BS is an ante into the game, but after that both the academic and the street-smart have to play their cards well to advance.
I'm going to go all terminology-pedant on you, because I've been hearing the wingnut teabaggers misuse "communist", "socialist", and "fascist" for a while now as fear words.
Communism is a *socioeconomic* philosophy, where property is held in common, particularly means of production, with common access to means of consumption. It has nothing to do with quantity or quality of government regulation.
Totalitarianism is a *political* philosophy where the state recognizes no bounds to its power to control the actions and lives of its citizens/subjects.
Many Communist countries also had Totalitarian governments, because unless you have a very small, commonly-aligned populace, everyone must be forced to participate in a communist system for it to function as intended. However, you can have one without the other.
You say "communist", you mean "totalitarian."
The link you provide speaks to the problems of bit-packing on the symbol states, and the solution of Trellis Modulation, which I mentioned. Trellis coding allowed for packing more than 4 bits to each symbol without increasing the error rate, leading to the development of the v.32bis standard and 14.4Kbps modems. Which is what I said - it wasn't high baud rates, but better bit packing that realized faster speeds.
And you're still saying "baud" when you mean "bits per second".
I think you're just misunderstanding the problem.
The "baud rate" of telephone lines is pretty slow. Baud rate is the number of symbol transitions per second the media can support. Baud rate and bits/second have not been equivalent since Bell103a/V.21 frequency-shift-keyed modems, where 300 baud meant 300 bps, each state transition being a discrete tone that indicated a "mark" or "space" (0/1). From then on, Bell 212a/V.22 used phase-shift keying to get 1200 bps out of a 600 BAUD symbol rate, encoding two bits of information per symbol.
POTS lines are pretty pokey - the practical maximum BAUD rate is less than 3500 symbols/sec. Where speed advancements were made in later evolutions of POTS modems were in the number of bits that could be encoded per symbol, using QAM and Trellis Modulation. A 33.6 kbps modem is encoding 10 bits per symbol onto a 3429 baud carrier.
So, when you kept hearing "phone lines max out at less than 4800 baud", that was correct. The engineers kept wringing higher bit rates out of narrow-band POTS by putting more information on each of the symbols transmitted.
Then, with V.70 and V.90, the modulation schemes took advantage of certain characteristics of non-muxed POTS lines to use PCM digital encoding instead of an analog audio carrier. Unfortunately, if you were serviced through a SLC-96 ("Slick") muxed subscriber loop, which multiplexed the signal from your subscriber line to the central office, you could only connect with older analog modulation schemes such as v.32/v.32bis/v.34.
Don't want to reduce your smug, but we're doing just this - restart services from the failed component, service the failed resource on a non-critical timeframe. The small shop with a half-dozen server boxes doesn't give a damn about cooling costs or this level of service, for the most part. If they do, they're likely going to someone else to satisfy that requirement, not doing it in house.
I've got stack of servers in my datacenter that are allocatable on demand. Any unused server blade is a potential spare. If a production blade tips over with a CPU fault, memory error, or similar crash, its personality (FC WWN's, MAC's, boot and data volumes, etc.) are moved to another blade and powered on through an automated process. Since the OS and apps live on the SAN, both VMs and dedicated server hardware can be abstracted away from the actual services they provide.
This is a product my company's selling to the market at large right now, and that I designed. Any of our IaaS customers can take advantage of the redundancy and fault tolerance built into the system. Even the six-server small IT shop.
Even then, a small IT organization can easily virtualize and provide some level of HA services in hypervisor clusters now. It's just not that hard anymore. Take the handful of servers you're running on now, replace them with an equal number of nodes in a VMM cluster, and go to town. Any of those systems fails, shift the load to the other nodes and effect repairs.
"Cloud computing," while it has very nearly achieved meaningless buzzword status, is an attempt by the business and marketing types to get their heads around what is a very real evolutionary transformation occurring in IT. The drivers are the drying up of CapEx budgets, the need to reduce service delivery time, and the requirement to purchase and pay for only what an organization needs to fulfill their business requirements.
Capital expenditures are coming under increased scrutiny, and are under constant budgetary pressure. "Cloud" based, on demand services allow IT service procurers to shift from a CapEx based model of owning the infrastructure to an OpEx model. Operational expenditures are typically larger chunks of budget than capital purchases, and moving IT services there can allow them to get "lost in the noise". Less red tape, less stringent approval processes, etc.
Time to deliver service is a labor cost, and if a procurer can shift that operational expense from internal overhead required to deploy an IT architecture to acquiring those same services from a cloud provider, it's perceived as a big win. The provider gets to deal with the headaches of capacity management, infrastructure design and integration, and delivering IT resources. The purchaser gets the luxury of simply specifying how much they want, for how long, and letting the provider leverage its economies of scale and automated processes to deliver the resources within the terms of the provider's SLA. The tradeoff is that the consumer of cloud services loses the ability to specify the platform and all its parameters in exchange for rapid delivery of a standardized service.
IT organizations are also under increased pressure to abandon the concept of designing and purchasing for peak capacity. Cloud providers are specifically addressing these needs by allowing their customers to pay only for what they use, not the spare capacity. Since the "cloud" capacity is shared, reused, and managed by the provider, the customer is afforded the ability to scale their environment dynamically to meet the needs of the business and its budget.
Now, how this ties into Web Services is important. Web Services, for a long time, was a solution in search of a well-defined problem. Now, with the "cloud" becoming a workable construct, Web Services come to the forefront as the way that stateless platforms can interact without intimate knowledge of the underlying infrastructure. Web Services will become more and more important as IT services are increasingly abstracted away from the hardware and OS platform. As I've worked for the past two years as a design architect for an infrastructure-as-a-service type platform, I can say with some authority that they're are an integral part of how we're going to need to deal with virtualized environments and stateless service contexts as they become pervasive elements of IT solutions.
Yes, technical tests are fair, and required.
Recruiting agencies will put everything and anything on a candidate's resume. Their people are evaluated by how many interviews they can schedule, and how many placements they achieve. So, they will stack the applicant's CV with anything that's ever been in the same 10-mile radius as the individual in question.
The result is that you're faced with a piece of paper that looks identical to every other programmer's. It's an alphabet soup - .NET, C#, Java, C, C++, Python, .NET, ASP, ADO, JDBC, XSLT, VB, XML, SQL, BLAHBLAHBLAH. And every programmer lists every one of these. Even the projects look the same - "Senior programmer for web development project implementing a user portal and reporting system for... etc, etc, etc." I have a stack of 12 resumes sitting here in front of me, and could literally swap the names in the header and you wouldn't be able to tell the difference.
So, we make a first pass, weeding out those who a) can't write, even after the headhunter has spiffied their CV, b) are scant with details, and c) hop assignments every three months. The rest have to do a preliminary interview, and that mainly consists of determining whether or not they actually know any of the stuff that their resume's been padded with. Sure, we ask the traditional interview questions, but we also do a base knowledge test. You would be surprised how many .NET "programmers" we get who don't know the most basic C# operations, web developers who don't know the difference between POSTing and GETting form data, and "7+ years experience SQL" applicants who can't tell you how a left outer join works.
Programmer's resumes are becoming increasingly useless, especially when you're flooded with nearly identical H1-B applicants with the same vague academic credentials (ie: "BS Elec. Eng., India", "Masters of Computer Applications" - no institution listed, "Bachelor of Engineering" - no discipline given), identical alphabet soup, and interchangeable litanies of 6-month contracts scattered about the country. They all have widely varying levels of competence that is in no way obvious from their resume. They all have "7+ years experience." That's what makes up 90% of the programmer pool these days, and even if you're in the top 10% with verifiable credentials and a real track record, you're gonna have to go through the same process. Because those of us on the hiring end can't tell anymore from your paperwork, without giving you some sort of objective evaluation of skills, syntax, and basic concepts.
It's been the rule for some time now. Ten years ago, it was all of the newly minted MCSEs rolling out of the fly-by-night tech schools. Before that, it was the "paper CNA/CNE's" who were able to sit the Netware exams and pass by the grace of their deity of choice. And there have always been the code-monkey grindhouse diploma-mill shops, who crank out "programmers" in the language du jour - especially since the web boom - CGI, Java, .NET, AJAX. All with credentials like "Doctor of Divine Coding" and the real competency of an ADD third-grader.
So, don't take it as a personal insult. You may be better than all of the above, but no one can determine that from a piece of paper, a firm handshake, and a good story about how you were the lead coding god on your last project. 'Cause there's a dozen other applicants out there with the same spiel.
By no means was the PC20-III (bollixed the model# the first time 'round) a particularly stellar box - never claimed that it was. It was just a successor to my old caffe-brown C-64 (with a breakout box ribbon cable soldered to the modem port for the 1670, and a stereo-SID mod). Not nearly as expensive as a Compaq or IBM toaster, and better than the Leading Edge dreck that was targeted to the consumer market. However, it was still a PC-clone, but that's what I needed at the time. The Amiga, as swell a design as it might have been, was too expensive to be a gamer (like the C64/128) and too outside the mainstream to be a viable competitor to the PC or Mac. And for almost two decades now, the Amiga fanboys have been wistfully stroking themselves to fond memories of Guru Meditations to realize that it was an overly complex design that was a business nightmare for its creators. Too expensive to build, too expensive to sell, margins sliced to the bone to make them "affordable." Visionary, we can debate, but absolute crap business sense. The only mid-to-long-term good that came out of the Amiga project was Ensoniq. The ESQ-1, SQ-80 and VFX-SD did more to change the synth world than the Amiga did to revolutionize personal computing.
That's a good question - I don't remember. I'd think that they were CBM machines, not just a rebadged beige-box, because of two things. The BIOS was ©CBM, I do know that. Second, the proprietary Commodore mouse (IIRC, the same mouse as the Amiga). Of course, this being almost 20 years ago, my crusty fogey-nerd memory could be failing me.
Sorry to break this to you, but even back when Commodore was still really Commodore, still selling the Amiga, way back there in the late 80's, they were also selling x86 boxen.
My first PC clone was (ghod help me) a Commodore PCIII-20, an 8088 machine (I later replaced the iNTEL chip with an NEC V-20) with 640K of RAM and an MFM HD-controller off of which hung a Seagate ST-225. CGA/Hercules mono on the motherboard! W00T! My original BBS ran on that box until I could replace it with a home-built 80286 machine (at a whopping 12MHz) with 1MB on the mboard and an AST Advantage/2 card for disk cache and external modem ports.
So, that brand's been long-sullied, almost 20 years ago, with PC-clone "blandness". Showrooms used to market the 68K-based Amigas and the PCs right next to each other.
You mean I can get 1980's "Midnight Madness", the cinematic master piece debut of one Mr. Michael J. Fox, in HD? All 23 times a week? Iron Eagle III? Bad 80's and 90's soft-core, too? The same "blockbuster" bombs over and over every night for a month, at a premium price? Tell me more! Ooo! Ooo! Miami Vice in HD! Omygodomygodomygodomygod... :faints:
I've replaced all the outside lighting and the utility lighting in the basement with CFLs. All in all, I've replaced 700W of incandescents with 137W of fluorescent. They're much brighter, faster to come to full output, and purer white than any compact fluorescent bulb from the last generation.
They're absolutely perfect for work and utility areas. For living areas and reading light, however, I still prefer tungsten bulbs.
Someone please enlighten the congresscritters that Furbies are so, like, 1998.
Well, I think the objection is more to those that call their wives (or whoever) in the grocery and stand there, oblivious to the world around them, as they block aisles and access to other shoppers while they blab away. Then, there's the just plain rudeness of having a high-volume, personal conversation in the middle of a public venue.
Standing off to the side, out of the way of the rest of the shoppers, and placing a quick call to find out what you can substitute for the crimini mushrooms that the store's out of? Great - go to it.
Standing in the middle of a busy aisle, babbling on about your plans for the weekend while everyone has to work around you? Having a profanity-laced argument in the checkout line? Being one of those nimrods that yammers on in their "outdoor voice" into one of those god-forsaken bluetooth earpieces as they wait at the deli, so that the guy behind the counter has to hold up service to interrupt you to find out how much olive loaf you want? Frackin' annoying as all hell.
Most people just don't get "courtesy first, your own amusement and/or gratification second." It's the nice little things that grease the wheels of polite society.
What these guys are doing is not compression. It's commonality factoring. No piece of data is ever stored more than once. Typically, this is done by a hashing algorithm that starts at a high level and indexes everything down to a discrete block size of a few K.
Each block gets an index checksum, then each file, each subdirectory, each parent directory, and so forth until the entire disk volume has a cumulative hash. Then, it's very easy to determine a) what has changed (and where), and b) what has been seen before.
When a backup starts, the client compares the volume hash signature to that on the backup system. If it matches - nothing has changed. Backup over. If it doesn't, then you walk the indexes to find out exactly what has changed, and then only prepare to send those dirs, files, or discrete blocks - whatever's the smalles object that expresses the delta. When those objects are queued to send to the repository, the client first generates a hash of the object and asks the repository if it's seen it before. If not, it sends the index and the data. If so, it sends nothing, since the repository's already got that particular chunk stored somewhere. There's some re-hashing and index reverification on the other end to make sure that all is consistent.
Therefore, each backup appears a "full" backup, not a file-level diff, since the entire image is comprised of a map of every object in the volume. In reality, each backup is a set of pointers into a hashed data store (commonly called a CAS, or Content Addressed Store) from which is is reconsitituted as needed.
Having tested and deployed one of these types of systems, I can say that a) it's great for desktops, where most of the data between boxes is identical - the OS, the core apps, etc, and only the user data and localization is different, and b) it's awful for pre-compressed data like streaming audio, video, JPEGs, PDFs, etc. Since compressed data is entropic data, there can be no commonality within the file or versions of it, unless the file itself is identical and present from multiple sources. Change one byte of a file and recompress it, and all the blocks are unique.
However, this is not new. Giggle Avamar Technologies and Arsenal Digital. BTW - this tech is pretty good for remote backups over low-bandwidth links, since it vastly reduces the amount of data that needs to traverse the wire.
Aircraft that are rated for ILS Cat-IIIa/b/c approaches can autoland with flare and rollout. The only thing that the pilot needs to do is pull the throttles over the numbers, and the plane will flare, settle to the runway, and rollout with autobraking (provided that brakes are armed). Cat-IIIc approaches are zero/zero - no decision height and down to zero visibility.
A Cat-III-rated aircraft has multiple, redundant autopilots, at least two of which must be functional and locked in to autoland. There are crosswind limitations, but your example (30KTS at 35 from centerline) is a headwind component of 24KTS and 17KTS crosswind component, both of which are within (for instance) the Cat-III autoland restrictions for the 747 (25KT headwind, 25KT crosswind).
I don't quite understand why everyone gets all up in Apple's shizznit about FairPlay. You do realize that once you have the FP-protected track on your machine, you can burn it to CD. Then, you can rip that track right back off your shiny new CD-R into whatever format you so choose, 100% DRM-free.
So yes, Apple supplies tracks that are DRM-protected. And even though we all know that all DRM schemes are the tool of Satan and his minions, at least Apple, ITMS, and FairPlay allow you to fairly freely media-shift that content. I know it's heretical to suggest to the /. crowd, but to me this seems like a pretty even balance. You can't just redistribute the AAC files, but by a trivial jump through the CD-R hoop, you can play ITMS content pretty much anywhere.
As to another point you made, if your software is telling you what to listen to, and you're obeying it, I somehow don't think that's Apple's fault.
It's not the reflective layer that degrades, but the organic dye that is used. All dyes degrade with age. The metal layer they're sandwiched with is mostly irrelevant.
Ah, but then your "macro" definition shifts dependent on the resolution of your sensor, not the size. You see, the reason that everyone's all catty-wumpus about this terminology is precisely because of the mixing in of elements of cropping, enlarging for prints, and so forth outside of the effect of the lens itself. I prefer to hold to the 1:1 reproduction ratio as the standard, from which you capture an image at various crop factors and resolutions. It's a definition that holds up no matter what the capture media, size, resolution, or method.
1:1 is not an arbitrary value - it is the intrinsic definition of the term "macro." Life-size or larger - the image formed on the focal plane of the lens must be at least as large as the object being represented. Whether a CCD sensor or a piece of film is placed at that focal plane is irrelevant.
If you photograph a 1/2" square, that it fills 1/80th of a 4x5" film sheet, 1/20th of a 6x6 medium format frame, about a fifth of a 35mm frame, or a little over half of a digital sensor makes no difference so long as the size of the projected image is also 1/2" or larger. You're confusing image size with cropping (which isn't something new that came along with digital cameras). Your assertion that "it's the results that count" is the exact same logic that produces a marketing-speak "macro zoom" with a 1:6 reproduction factor and a minimum focusing distance of three feet. As long as you can crop and produce a life-size enlargement, it doesn't matter? Sorry - not so. Go shoot a real 1:1 macro lens with a digital camera and then enlarge a crop of the same subject shot with a "macro zoom" kit lens to an identical size. Then get back to me about that "arbitrary value."
Focusing distance is not sufficient to qualify a lens as a macro. There are close focusing lenses that are not macro, and there are macro lenses with long focal lengths that don't focus particularly close.
A true "macro" lens is defined as a lens that allows for at least 1:1 reproduction of the subject image on the recording media. For the sake of simplicity, we'll talk film. If you photograph an object that is 1/2" across, and the resulting recorded image on the film is also 1/2" in size, you're shooting macro. A "macro lens" is one that is capable of rendering at least this 1:1 reproduction.
Unfortunately, many camera/lens manufacturer have abused the term to mean "focuses at a (slightly) closer distance than a normal lens at an identical focal length, so that when printed to standard 4x6 the image is life-size." This, of course, is regardless of the reproduction ratio of the lens. A rather silly definition, really, since any reasonable frame at any magnification can be cropped and enlarged to "life size" up to a point before quality degrades enough to become unworkable.
Amazon's camera sales are mostly fulfilled through Calumet or Adorama, and are dependent on them for delivery estimates. Adorama tends to close for extended periods to observe Jewish holidays (forget ordering anything from a NY camera store during late-September to mid-October, for instance). They source a few consumer-level products from electronics vendors.
However, if you order something sourced from Adorama during Sukkot - you're waiting a week before anyone even thinks about pulling it off the shelf.