Recent Features
| |||||||||||||
Fedora mulls ARM as a primary architectureFedora mulls ARM as a primary architecturePosted Mar 22, 2012 2:38 UTC (Thu) by slashdot (guest, #22014)Parent article: Fedora mulls ARM as a primary architecture
Well, of course all architectures must be cross compiled on x86-64!
Why the heck are they even considering using native compilation, which is just absurd, given that it gives no advantage, and that of course all non-x86-64 CPUs just suck horribly?
And what does many core have to do with it?
Just run distcc on an x86-64 cluster and cross-build everything...
BTW, in case they are worried about it, if a build system tries to execute a program it builds (= it's broken), just have qemu-arm set up to run it automatically.
If really needed, they can even just run a whole ARM distribution via qemu-arm on x86-64, and simply substitute gcc, as and ld with native x86-64 binaries, since they are usually the only performance critical programs.
Sometimes one wonders how things work at all, when the people in charge are so clueless.
(Log in to post comments)
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 2:54 UTC (Thu) by corbet (editor, #1) [Link] Come on, you don't need to talk about the people who are working to build free distributions that way. They have good reasons for being concerned about cross compilation and distcc. Maybe they'll eventually find ways around some of them, but they have thought about this stuff. "Clueless" is not fair and not conducive to a productive conversation.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 3:32 UTC (Thu) by jcm (subscriber, #18262) [Link]
Thanks Jon. In fact, we have thought about this stuff on many occasions. Indeed, some of our internal Red Hat ARM team members have looked into distcc for other purposes, and have produced some great numbers. Additionally, that scratchbox-like model has been around for a while and it works for many folks. Heck, a lot of us personally like cross-compilation and wish that it were always the case that it were a valid route. But...
Fedora (and other distros) haven't traditionally *done* cross-compilation for everything. We would have to fix a /lot/ of assumptions from the get go. So many that in fact I think we'd still be looking into that without the releases we have seen so far. Further, we want to be *boring* in ARM. We want to look and smell as much like x86 where it makes sense to do so. That means unless x86 is going to be cross-compiled (on a future 64-bit ARM system perhaps - and I'm not serious), we're not going to do something totally out of whack. No, we have to live with the world in which we live.
Jon.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 5:29 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> Fedora (and other distros) haven't traditionally *done* cross-compilation for everything. We would have to fix a /lot/ of assumptions from the get go.
In theory cross-compilation should be just as good as native, and helping to turn that into practice by creating heavy users would actually be lovely. Sadly this has become a lot harder (before it becomes easier one would hope) on Ubuntu 12.04 with their new multi-architecture system - at least many X11 development packages currently won't install for several architectures in parallel. At least in this case the fixes are not too hard, so I haven't yet given up hope for a fix before the actual release!
Back to Fedora though - if x86_64 is better at compiling and ARM at saving power, it seems to me that being able to build on x86_64 is a good example of what a cross-platform system is good for.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 6:50 UTC (Thu) by ttonino (subscriber, #4073) [Link]
Cross-platform building may make even more sense in the future as the gap between large and small systems continues to grow.
What if the distribution wants to run on a DSP based architecture with hard memory and storage limits?
In a sense, it is nearly always cross-compilation unless you compile Gentoo-style on the target box.
I'd say use the best tool for the box. Being able to cross-compile well also means that if ARM128 or PowerSparcWhatever would arrive, it could be used to do those x86-64 builds on.
So cross-compilation really solves tomorrows problems also if it means 'compile on the fastest system' and not 'compile on x86-64'.
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 20:11 UTC (Fri) by filipjoelsson (subscriber, #2622) [Link]
Gentoo'ers happily crosscompile too. I had a uclibc-box on 32-bit that used an amd64-box as distcc-slave - there's a lot of handy documentation on the concept.
I can see how the package/build system could get in your way if you're not constantly refining it (as Gentoo has a natural incentive to do). However, distcc goes out of its way to make these things easy, and I really do wonder if it has to be all that hard. I mean, the build can run on an ARM-box, which may share some of the build with an amd64-box by way of distcc. The way you'd achieve it is by putting the path with cc linked to distcc before the cc->gcc in the PATH. For builds that can't be distributed, just use the full path.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 10:56 UTC (Thu) by slashdot (guest, #22014) [Link]
This is, indeed, a prime example of cluelessness. Even worse, they don't even realize it!
First of all, you are supposed to be releasing good source code as well as binaries, and if cross compilation is so broken, you are supposed to fix it.
Second, even if you are totally lazy and don't want to fix it, YOU CAN WORK AROUND IT.
Again, simply build packages in a full ARM system (either native or running on x86 with qemu-arm), and then replace gcc, as and ld either with a distcc (or other remote) client, or if running in qemu, with native cross-compilers.
Of course, this should only be done if a package fails to build with normal cross compilation.
The idea of running a compile farm on an embedded architecture like ARM is just insane and idiotic.
I mean, if the next architecture you want to support only comes inside a dishwasher, do you purchase a cluster of dishwashers to build the distribution?
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 13:14 UTC (Thu) by khim (subscriber, #9252) [Link] First of all, you are supposed to be releasing good source code as well as binaries, and if cross compilation is so broken, you are supposed to fix it. Citation is needed really badly. I see no such requirements in GPLv2, GPLv3 or any other sane license. And I, for one, just flat our refuse to spend my time doing useless work. Sometimes cross-compilation makes sense (for example if I build package for Arduino), but often it's just easier to use native build. Again, simply build packages in a full ARM system (either native or running on x86 with qemu-arm), and then replace gcc, as and ld either with a distcc (or other remote) client, or if running in qemu, with native cross-compilers. This may break native compilation instead. Sometimes it's not a big deal (for example some ARM-packages here can not be build on ARM because linker needs >4GB of address space), but presumably they want to keep this possibility - and then it must be tested. The idea of running a compile farm on an embedded architecture like ARM is just insane and idiotic. Sure. As long as ARM remains “an embedded architecture”. But in this case it makes little sense to promote it to “primary architecture” status. The whole tempest started as admission that ARM is no longer just an embedded architecture. Well, if that's true then it should be capable enough to build itself.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 13:50 UTC (Thu) by slashdot (guest, #22014) [Link]
> I see no such requirements in GPLv2, GPLv3 or any other sane license.
It's not a legal requirement, but having a non-broken build system (which includes cross build capability) is a part of releasing open source quality software.
> This may break native compilation instead
Then test native compilation too once in a release cycle.
> Sure. As long as ARM remains “an embedded architecture”. But in this case it makes little sense to promote it to “primary architecture” status
Embedded architectures can be extremely important, since everyone uses a cell phone for instance; that doesn't mean it's a good idea to use them as build farm servers.
Maybe ARM servers will be viable eventually, but definitely not now.
For instance according to Wikipedia, Cortex A15 has 1/3 the Dhrystone IPC of Core i7 2600k, which isn't a good sign, although it could perhaps still win on system price/performance (kind of unlikely though).
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 15:53 UTC (Thu) by pboddie (subscriber, #50784) [Link] Embedded architectures can be extremely important, since everyone uses a cell phone for instance; that doesn't mean it's a good idea to use them as build farm servers. And this is a concern right now for anyone doing development for things like mobile phones. The attitude amongst the people who are supposedly most active (and best funded) has apparently mostly been to ignore the need for a decent cross-compilation workflow and instead either claim that running the compiler on a phone is "not that bad" or use second-rate workarounds like qemu, wasting an absurd amount of CPU time and energy emulating a native compiler and toolchain. It should be completely possible to cross-build a distribution: very little code is actually in an architecture-specific machine language, and the build process should be using portable languages as well. I have high hopes that stuff like multiarch will help to work around the issues with tools and their liking for specific, immutable filesystem paths. That cross-building cannot be done for a distribution (various Debian-related efforts seem to undermine such claims) shouldn't be an excuse for not doing anything about it. It has been over two decades since ARM had any kind of performance advantage over mainstream architectures, and although you can certainly go and buy a bunch of ARM-based devices to do parallel native builds, and although the performance per core of ARM-based devices is improving, it's wasteful and absurd to suggest that people would go and buy a cluster of modestly performing gadgets when the machine on their desk/lap/rack could race through the process in comparatively little time. To label anyone as clueless may be rude, but it is fair to state that the situation is ridiculous.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 18:05 UTC (Thu) by wookey (subscriber, #5501) [Link]
Having been involved in arm support in Debian for 13 years and this (cross-building) debate for much of that time it's kind of amusing to see the reaction in Fedora-land with talk of the 'craziness' of native build farms for slow arches and the 'idiocy' of not cross-building everything.
Debian has of course been doing this (native building on build farms for all arches)for 15 years. The distro isn't broke because of it, in fact code quality is dramatically improved as a result, but yes, security updates do take longer. And yes you have to do some things differently (like not doing regular complete-rebuilds on all arches).
Cross-building will never be as reliable as native-building. You can't run tests*, and for some things at least you can't ask the machine: you have to ask some config, which is more likely to get stale than the machine. That's _why_ it's good CS practise to run configure- and build-time tests to check things, which is why builds increasingly do this. Calling it 'broken' is hopelessly simplistic. This trend does annoy the hell out of cross-compiling peeps.
On the other hand cross-building remains useful even as ARM hardware gets faster, and it could work a whole heap better than it does now (in Debian/Ubuntu). Multiarch is indeed a big part of making that reliable, but there will always be tradeoffs, as anyone who's actually done some will be able to tell you.
If anyone _is_ interested in making ARM cross-building work better in the multi-arch context, then do please look at my multiarch cross-autobuilder and fix things (as you'll see there is plenty to fix right now as the state could reasonably be summarised as 'mostly broken'). It's particularly bad today as there is version skew on libc so almost no cross-build-deps installed):
Of course that's just Ubuntu (Debian unstable will be added shortly now that multiarch dpkg has finally arrived). Fedora is not (yet?/ever?) using multiarch so would need to use a different cross-build mechanism anyway, such as the Open Build System or Scratchbox models ('fake-native' building using emulation and native back-end tools such as the compiler), or classical/sysroot mechanisms.
Personally I think it's important that cross-building works as well as it reasonably can in a distro, for the same reasons that it's good for a distro to build properly on lots of architectures. It improves code quality, roots out things that are just plain wrong, and makes things like bootstrapping new ports and rebuilding for optimisations _much_ easier.
But suggesting that a whole distro should be built this way does not make much sense outside of some relatively small use-cases (e.g. arches where you have no choice such as AVR, and subset rebuilds for speed reasons, and for build-time configurability of the sort that Yocto/OE/buildroot/openbricks/ptxdist take advantage of). Native-building must be considered canonical for large binary-package distros, and cross-building will remain subsidiary to that.
All IMHO of course, but I claim to have some clue.
* You might be able to run tests via qemu, but that may be available for the target arch and it may not give the same results.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 19:30 UTC (Thu) by jcm (subscriber, #18262) [Link]
Jon Corbet, can you please add a G+ style "+1" button so I can go around +'ing everything wookey says? ktnxbye.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 22:35 UTC (Thu) by pboddie (subscriber, #50784) [Link] I don't disagree with most of what you've written, but I will dispute the following: Cross-building will never be as reliable as native-building. You can't run tests*, and for some things at least you can't ask the machine: you have to ask some config, which is more likely to get stale than the machine. There are configuration-level tests which I accept are difficult to manage unless you're building natively, and there are validation-level tests which are actually needed to show that the executables really do work on the target hardware, but I see no need to punctuate the build process with the latter and permeate the process with native executable dependencies. It's a bit like the multi-stage aspect of things like debootstrap: a certain amount of time can be done without depending on the target environment, and then stuff that actually requires the target environment can be done there. Where ample resources are available to do the heavy lifting of compilation on one architecture, it's wasteful to disregard those and to put the burden on the target architecture. I look forward to the point where people try and build PyPy for ARM - that's already a very heavy (and not parallelised) exercise on x86(-64) requiring a fast CPU and lots of RAM - so the case for cross-compilation isn't a curious historical anomaly just yet.
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 1:02 UTC (Fri) by wookey (subscriber, #5501) [Link]
Yes, you are right that it makes a lot of sense to separate out the validation tests into something that is run later on the real hardware (not least becuase the build hardware and the runtime hardware may not pass/fail in exactly the same way). The catch is that most build-systems include the tests as one of the build targets and expect to do them at build-time using build-time paths and the source code files, not later, using install-time paths and the files available in the installed package.
We probably could fix this - I must admit I've not really looked at it in any detail. Maybe it's not even too difficult?
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 5:30 UTC (Fri) by khim (subscriber, #9252) [Link] We probably could fix this - I must admit I've not really looked at it in any detail. Maybe it's not even too difficult? it's not that difficult to fix, but it's PITA to keep fixed. Unless you are doing cross-compilation geared project like Android (in which case on-target compilation bitrots instead).
Fedora mulls ARM as a primary architecture Posted Apr 4, 2012 20:09 UTC (Wed) by cmsj (guest, #55014) [Link]
Fortunately pypy has a fast build time on arm at the moment because it ftbfs after 6 minutes ;)
https://launchpad.net/ubuntu/+source/pypy/1.8+dfsg-2/+bui...
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 12:16 UTC (Fri) by nhippi (subscriber, #34640) [Link]
Cross-building, as enabled in debian via multi-arch, isn't really intended for crossbuilding the distro except for special cases. Such as bootstrapping a new architecture.
The main target of cross-building is developers, who want to run their edit - build - run - debug cycle as fast as possible.
For building a distro, native building enables the eat-our-own-dogfood testing of all the build tools. It is not just the testsuites, but everything that is run during builds.
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 23:53 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
there were discussions just recently about how RHEL/CentOS is a hard thing to maintain because the packages aren't compiled with the compiler and libraries shipped with RHEL.
this makes me doubt the 'eat your own dogfood' justification. There is some of that, but it's a rule they break in so many other cases (because it's so much work to compile everything)
Fedora mulls ARM as a primary architecture Posted Mar 24, 2012 0:07 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]
You misunderstood the situation. Packages *are* built with the compiler in RHEL however during the development of a release, the compiler or libraries sometimes gets bumped up and not everything is rebuild because it would invalidate testing to some extend and this isn't specific to RHEL. Packages fail to build from source in other distributions as well. Usually they have some tracking mechanism to minimize this.
Cross-compilation Posted Mar 22, 2012 8:42 UTC (Thu) by rvfh (subscriber, #31018) [Link]
I am part of a team creating packages for ARM, and believe me, if we could safely cross-compile in a few seconds rather than native-compile in a few minutes we'd do it (it's not always hours!) But not that many packages are easily cross-compiled, and a number of issues tend to arise later on the running system.
We only cross-compile the kernel for development, but then native-compile it for the releases.
What is more, given the performance of the new CPUs (for example the Cortex-A15 you can find in TI's OMAP5 and Samsung's Exynos 5250), cross-compiling is indeed yesterday's problem.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 10:04 UTC (Thu) by mpr22 (subscriber, #60784) [Link] BTW, in case they are worried about it, if a build system tries to execute a program it builds (= it's broken) Out of interest, what's "broken" about writing the parsers that turn your human-readable data into the deliverable binaries in lex and yacc instead of $runtime_parsed_language (and would you care to explain it to the Nethack Dev Team)?
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 14:05 UTC (Thu) by Yorick (subscriber, #19241) [Link]
Indeed. Some of the time, staged builds can be made cross-safe (flex and bison can usually run on the build machine), but not always. For instance, a program that extracts struct member offsets from data structures for use in assembly routines. Or unit tests - fragments of a program that are run during or right after the build to make sure that they work correctly.
Perhaps most of these obstacles can be overcome by interposing an emulator into the build system for the execution of target code, but even with a fully-functional emulator, such an undertaking requires substantial effort and expertise for every package. And running the entire build inside an emulator is likely to be no faster than using native hardware.
I'm not fond of autoconf and its associated tools, but mainly because of their cruftiness (shell scripts, m4 macros) and how they seem to be designed for solving yesterday's problems. A modern software configuration and build system that makes it easy to do cross-buildable packages would be useful.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 13:10 UTC (Thu) by juliank (subscriber, #45896) [Link]
> BTW, in case they are worried about it, if a build system
> tries to execute a program it builds (= it's broken), > just have qemu-arm set up to run it automatically.
Running build-time tests is surely not broken, but good practice. And using qemu to run them is broken, as the emulation is not good enough and may actually run more programs than a native ARM would run (i.e. unaligned memory accesses are not catched in qemu). Thus, tests could run fine on the emulated build system, but the code fails to run on the native system.
Fedora mulls ARM as a primary architecture Posted Mar 23, 2012 16:29 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
Those same problems occur if you use a build machine whose processor supports more features than the minimum supported processor. (And you surely will.)
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 13:16 UTC (Thu) by hanwen (subscriber, #4329) [Link] if a build system tries to execute a program it builds (= it's broken)I've written a lot of code to make common linux packages cross-compile, and I think the fedora team is completely right to avoid it. Packages that build and execute stuff to build are broken for cross-compile, but unfortunately, they are also exceedingly common. Any package that is some sort of platform needs to read its own platform definitions/programs, either to prepare the platform or to document it. Examples: ghostscript, python (and all other interpreters), every compiler (look at the horrendous 3 phase build of GCC), document processing (eg. LaTeX), programs that work with interface definitions (like protocol buffers and IDL files). You can run all these binaries on an emulator, but that will hardly be faster than running on the target system to start with. Getting packages to work for cross compiling is a painful process of infinite recompiles, where you have to figure which parameters (eg. the ones from autoconf configure) should come from the target, and which ones from the host, then the same for the object files. Root cause of the problem are the make/autoconf build tools that work on arbitrary files and arbitrary variables, so the distinction between host and target is not made explicit.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 13:36 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
go read rob landley's blog http://landley.net/notes.html for a peek into the horror story that cross compiling, and even trying to compile with qemu can run into. doing this for an entire distro seems like a risky thing.
That being said, I am amazed that anything more than a one-person distro isn't using distcc or similar to spread the compile load over a farm of machines.
Getting lots of ARM machines for this sort of thing is pretty easy, and power wise is far more efficient than any x86 machine. People make off-the-shelf boxes which have dozens of ARM SoC systems plugged into them. individually they are poor, but as a compile farm they would be very efficient (the final serialized link step would still be a bottleneck, but that's a small part of the overall CPU time)
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 15:10 UTC (Thu) by rwmj (subscriber, #5474) [Link]
There's no problem using distcc (in fact, it's fairly trivial to add).
The problem is that you get hit by Amdahl's law: single builds are simply not very parallelizable. Recursive Makefiles have to be run sequentially. Even a large project may only have dozens of C files, but to really exploit multicore ARM you need hundreds of parallel tasks. Tests have to run sequentially (at least, they do when using automake). There's a fixed "top and tail" overhead of unpacking the tarball and constructing the final package.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 15:42 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
The article seemed to be indicating that distcc was receiving almost as much pushback as cross compiling.
as for the "tip and tail" overhead, that's one place where I would say to use a amd64 machine, use it to unpack the tarball onto a network accessible drive and then package up the result. Ideally you do this on the machine providing the network accessible drive so that it's all local I/O.
This isn't going to scale linearly with the number of machines for any one package build, but there are a LOT of packages that need to be built, so overall you should be able to keep dozens, if not hundreds of cores busy.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 19:33 UTC (Thu) by nix (subscriber, #2304) [Link]
Automake grew support for parallel tests in 1.11.
Fedora mulls ARM - Is tar holding us back? Posted Mar 25, 2012 3:33 UTC (Sun) by ndye (subscriber, #9947) [Link] Amdahl's law [shows up in] a fixed "top and tail" overhead of unpacking the tarball . . . With horizontal scaling defining the future, should we consider an archive format with a random-access catalog (like ZIP) to replace linear tar? (Just an idea.)
Fedora mulls ARM - Is tar holding us back? Posted Mar 26, 2012 4:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
There's Duplicity[1], but AFAICS, it's gone approximately nowhere so far.
Fedora mulls ARM as a primary architecture Posted Apr 4, 2012 19:53 UTC (Wed) by cmsj (guest, #55014) [Link]
You also hit cmsj's law, which states that all ARM hardware is fundamentally opposed at a sub-atomic level, to the calm and peaceful mental state of sysadmins ;)
(which is to say that all of the currently available ARM hardware is extremely unreliable under continuous duress, and none of the hardware is built for low friction remote management. This will change when ARM servers are a real thing, but for now I welcome the work being done by Linaro folks to enable Ubuntu building ARM packages with qemu!)
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 15:34 UTC (Thu) by slashdot (guest, #22014) [Link]
Most of the build time is of course spent running gcc and ld, so even if you have to run everything else in an emulator, it's still likely much faster.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 20:42 UTC (Thu) by oak (guest, #2786) [Link]
GCC takes a lot of time, especially for C++, but all the autotools stuff, package management etc take also surprising amount of time. With small software packages that's significantly more time than what the compiler takes, with larger packages, it can still be several tens of percents.
Scratchbox2 is designed to deal also with that:
It uses LD_PRELOAD and other techniques to map file accesses to host binaries, runs cross-compiled code through Qemu (again, with path mapping) and so on. It's used by Tizen, MeeGo's Mer successor, was available for building Maemo stuff is and packaged in Debian (since Lenny) & Ubuntu (since Hardy).
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 16:02 UTC (Thu) by pboddie (subscriber, #50784) [Link]
CPython's build process is broken for cross-compilation and despite various patches to fix it, there's no interest amongst the core developers in doing much about the situation, unfortunately.
There's actually hardly any reason to do what the Python build process does, which is to run the built executable in order to perform a bunch of tasks that could in many cases be done by a suitable host-native executable: compiling .py files to .pyc files merely demands an executable supporting the same Python version, not the specific executable to be run in the target environment; copying files into a particular location does not depend on executing ARM code just because the target device happens to use an ARM CPU.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 17:24 UTC (Thu) by wookey (subscriber, #5501) [Link] Well, of course all architectures must be cross compiled on x86-64!Everyone else seems to have taken this comment seriously, and carefulkly rebutted it. I assumed it to be obvious satire. But if course if satire is correctly pitched it can be quite hard to tell if it is or not...
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 19:34 UTC (Thu) by jcm (subscriber, #18262) [Link]
Ah yes, on second reading, I do see it now. I've lived in the US so long that I've started to forget what "sarcasm" is (which here is just a byword for something "mean", which is not the same thing at all). Thanks my English friend ;)
Jon.
Fedora mulls ARM as a primary architecture Posted Mar 22, 2012 23:39 UTC (Thu) by giraffedata (subscriber, #1954) [Link] if satire is correctly pitched it can be quite hard to tell if it is or not... I would call that incorrectly pitched. Satire is supposed to make a point and if readers don't recognize it as satire, it doesn't. In fact, it does worse than say nothing at all. And it's a well known fact that sarcasm doesn't work in written discussions like this one. Seasoned participants know not to try it. My personal policy is always to assume a person in a forum like this said what he meant, even if I have a strong suspicion it was meant sarcastically. It's more confusing, not to mention disrespectful, to do otherwise.
|
|||||||||||||