@FIXME{need an intro here}
tar
Archives More PortableCreating a tar
archive on a particular system that is meant to
be useful later on many other machines and with other versions of
tar
is more challenging than you might think. tar
archive formats have been evolving since the first versions of Unix. Many such
formats are around, and are not always comptible with each other. This section
discusses a few problems, and gives some advice about making tar
archives more portable.
One golden rule is simplicity. For example, limit your tar
archives to contain only regular files and directories, avoiding other kind of
special files. Do not attempt to save sparse files or contiguous files as such.
Let's discuss a few more problems, in turn.
Use straight file and directory names, made up of printable ASCII characters, avoiding colons, slashes, backslashes, spaces, and other dangerous characters. Avoid deep directory nesting. Accounting for oldish System V machines, limit your file and directory names to 14 characters or less.
If you intend to have your tar
archives to be read under MSDOS,
you should not rely on case distinction for file names, and you might use the
GNU doschk
program for helping you further diagnosing illegal MSDOS
names, which are even more limited than System V's.
Normally, when tar
archives a symbolic link, it writes a block
to the archive naming the target of the link. In that way, the tar
archive is a faithful record of the filesystem contents.
--dereference (-h) is used with --create
(-c), and causes tar
to archive the files symbolic links
point to, instead of the links themselves. When this option is used, when
tar
encounters a symbolic link, it will archive the linked-to file,
instead of simply recording the presence of a symbolic link.
The name under which the file is stored in the file system is not recorded in
the archive. To record both the symbolic link name and the file name in the
system, archive the file under both names. If all links were recorded
automatically by tar
, an extracted file might be linked to a file
name that no longer exists in the file system.
If a linked-to file is encountered again by tar
while creating
the same archive, an entire second copy of it will be stored. (This
might be considered a bug.)
So, for portable archives, do not archive symbolic links as such, and use --dereference (-h): many systems do not support symbolic links, and moreover, your distribution might be unusable if it contains unresolved symbolic links.
Certain old versions of tar
cannot handle additional information
recorded by newer tar
programs. To create an archive in V7 format
(not ANSI), which can be read by these old versions, specify the
--old-archive (-o) option in conjunction with the
--create (-c). tar
also accepts
`--portability' for this option. When you specify it,
tar
leaves out information about directories, pipes, fifos,
contiguous files, and device files, and specifies file ownership by group and
user IDs instead of group and user names.
When updating an archive, do not use --old-archive (-o) unless the archive was created with using this option.
In most cases, a new format archive can be read by an old
tar
program without serious trouble, so this option should seldom
be needed. On the other hand, most modern tar
s are able to read old
format archives, so it might be safer for you to always use
--old-archive (-o) for your distributions.
tar
and POSIX tar
GNU tar
was based on an early draft of the POSIX 1003.1
ustar
standard. GNU extensions to tar
, such as the
support for file names longer than 100 characters, use portions of the
tar
header record which were specified in that POSIX draft as
unused. Subsequent changes in POSIX have allocated the same parts of the header
record for other purposes. As a result, GNU tar
is incompatible
with the current POSIX spec, and with tar
programs that follow it.
We plan to reimplement these GNU extensions in a new way which is upward
compatible with the latest POSIX tar
format, but we don't know when
this will be done.
In the mean time, there is simply no telling what might happen if you read a
GNU tar
archive, which uses the GNU extensions, using some other
tar
program. So if you want to read the archive with another
tar
program, be sure to write it using the
`--old-archive' option (`-o').
@FIXME{is there a way to tell which flavor of tar was used to write a particular archive before you try to read it?}
Traditionally, old tar
s have a limit of 100 characters. GNU
tar
attempted two different approaches to overcome this limit,
using and extending a format specified by a draft of some P1003.1. The first way
was not that successful, and involved `@MaNgLeD@' file names, or such;
while a second approach used `././@LongLink' and other tricks, yielding
better success. In theory, GNU tar
should be able to handle file
names of practically unlimited length. So, if GNU tar
fails to dump
and retrieve files having more than 100 characters, then there is a bug in GNU
tar
, indeed.
But, being strictly POSIX, the limit was still 100 characters. For various
other purposes, GNU tar
used areas left unassigned in the POSIX
draft. POSIX later revised P1003.1 ustar
format by assigning
previously unused header fields, in such a way that the upper limit for file
name length was raised to 256 characters. However, the actual POSIX limit
oscillates between 100 and 256, depending on the precise location of slashes in
full file name (this is rather ugly). Since GNU tar
use the same
fields for quite other purposes, it became incompatible with the latest POSIX
standards.
For longer or non-fitting file names, we plan to use yet another set of GNU
extensions, but this time, complying with the provisions POSIX offers for
extending the format, rather than conflicting with it. Whenever an archive uses
old GNU tar
extension format or POSIX extensions, would it be for
very long file names or other specialities, this archive becomes non-portable to
other tar
implementations. In fact, anything can happen. The most
forgiving tar
s will merely unpack the file using a wrong name, and
maybe create another file named something like `@LongName', with the
true file name in it. tar
s not protecting themselves may segment
violate!
Compatibility concerns make all this thing more difficult, as we will have to
support all these things together, for a while. GNU tar
should be able to produce and read true POSIX format files, while being able to
detect old GNU tar
formats, besides old V7 format, and process them
conveniently. It would take years before this whole area stabilizes...
There are plans to raise this 100 limit to 256, and yet produce POSIX
conformant archives. Past 256, I do not know yet if GNU tar
will go
non-POSIX again, or merely refuse to archive the file.
There are plans so GNU tar
support more fully the latest POSIX
format, while being able to read old V7 format, GNU (semi-POSIX plus extension),
as well as full POSIX. One may ask if there is part of the POSIX format that we
still cannot support. This simple question has a complex answer. Maybe that, on
intimate look, some strong limitations will pop up, but until now, nothing
sounds too difficult (but see below). I only have these few pages of POSIX
telling about `Extended tar Format' (P1003.1-1990 -- section 10.1.1), and there
are references to other parts of the standard I do not have, which should
normally enforce limitations on stored file names (I suspect things like fixing
what / and NUL means). There are also some
points which the standard does not make clear, Existing practice will then drive
what I should do.
POSIX mandates that, when a file name cannot fit within 100 to 256 characters
(the variance comes from the fact a / is ideally needed as the 156'th
character), or a link name cannot fit within 100 characters, a warning should be
issued and the file not be stored. Unless some --posix
option is given (or POSIXLY_CORRECT
is set), I suspect that GNU
tar
should disobey this specification, and automatically switch to
using GNU extensions to overcome file name or link name length limitations.
There is a problem, however, which I did not intimately studied yet. Given a
truly POSIX archive with names having more than 100 characters, I guess that GNU
tar
up to 1.11.8 will process it as if it were an old V7 archive,
and be fooled by some fields which are coded differently. So, the question is to
decide if the next generation of GNU tar
should produce POSIX
format by default, whenever possible, producing archives older versions of GNU
tar
might not be able to read correctly. I fear that we will have
to suffer such a choice one of these days, if we want GNU tar
to go
closer to POSIX. We can rush it. Another possibility is to produce the current
GNU tar
format by default for a few years, but have GNU
tar
versions from some 1.POSIX and up able to recognize
all three formats, and let older GNU tar
fade out slowly. Then, we
could switch to producing POSIX format by default, with not much harm to those
still having (very old at that time) GNU tar
versions prior to
1.POSIX.
POSIX format cannot represent very long names, volume headers, splitting of
files in multi-volumes, sparse files, and incremental dumps; these would be all
disallowed if --posix or POSIXLY_CORRECT
. Otherwise, if
tar
is given long names, or `-[VMSgG]', then it should
automatically go non-POSIX. I think this is easily granted without much
discussion.
Another point is that only mtime
is stored in POSIX archives,
while GNU tar
currently also store atime
and
ctime
. If we want GNU tar
to go closer to POSIX, my
choice would be to drop atime
and ctime
support on
average. On the other hand, I perceive that full dumps or incremental dumps need
atime
and ctime
support, so for those special
applications, POSIX has to be avoided altogether.
A few users requested that --sparse (-S) be always
active by default, I think that before replying to them, we have to decide if we
want GNU tar
to go closer to POSIX on average, while producing
files. My choice would be to go closer to POSIX in the long run. Besides
possible double reading, I do not see any point of not trying to save files as
sparse when creating archives which are neither POSIX nor old-V7, so the actual
--sparse (-S) would become selected by default when
producing such archives, whatever the reason is. So, --sparse
(-S) alone might be redefined to force GNU-format archives, and
recover its previous meaning from this fact.
GNU-format as it exists now can easily fool other POSIX tar
, as
it uses fields which POSIX considers to be part of the file name prefix. I
wonder if it would not be a good idea, in the long run, to try changing
GNU-format so any added field (like ctime
, atime
, file
offset in subsequent volumes, or sparse file descriptions) be wholly and always
pushed into an extension block, instead of using space in the POSIX header
block. I could manage to do that portably between future GNU tar
s.
So other POSIX tar
s might be at least able to provide kind of
correct listings for the archives produced by GNU tar
, if not able
to process them otherwise.
Using these projected extensions might induce older tar
s to
fail. We would use the same approach as for POSIX. I'll put out a
tar
capable of reading POSIXier, yet extended archives, but will
not produce this format by default, in GNU mode. In a few years, when newer GNU
tar
s will have flooded out tar
1.11.X and previous, we
could switch to producing POSIXier extended archives, with no real harm to
users, as almost all existing GNU tar
s will be ready to read
POSIXier format. In fact, I'll do both changes at the same time, in a few years,
and just prepare tar
for both changes, without effecting them, from
1.POSIX. (Both changes: 1--using POSIX convention for getting over
100 characters; 2--avoiding mangling POSIX headers for GNU extensions, using
only POSIX mandated extension techniques).
So, a future tar
will have a --posix flag forcing the
usage of truly POSIX headers, and so, producing archives previous GNU
tar
will not be able to read. So, once pretest will
announce that feature, it would be particularly useful that users test how
exchangeable will be archives between GNU tar
with
--posix and other POSIX tar
.
In a few years, when GNU tar
will produce POSIX headers by
default, --posix will have a strong meaning and will disallow GNU
extensions. But in the meantime, for a long while, --posix in GNU tar
will not disallow GNU extensions like
--label=archive-label (-V
archive-label), --multi-volume (-M),
--sparse (-S), or very long file or link names. However,
--posix with GNU extensions will use POSIX headers with
reserved-for-users extensions to headers, and I will be curious to know how well
or bad POSIX tar
s will react to these.
GNU tar
prior to 1.POSIX, and after
1.POSIX without --posix, generates and checks `ustar
', with two suffixed spaces. This is sufficient for older GNU
tar
not to recognize POSIX archives, and consequently, wrongly
decide those archives are in old V7 format. It is a useful bug for me, because
GNU tar
has other POSIX incompatibilities, and I need to segregate
GNU tar
semi-POSIX archives from truly POSIX archives, for GNU
tar
should be somewhat compatible with itself, while migrating
closer to latest POSIX standards. So, I'll be very careful about how and when I
will do the correction.
SunOS and HP-UX tar
fail to accept archives created using GNU
tar
and containing non-ASCII file names, that is, file names having
characters with the eight bit set, because they use signed checksums, while GNU
tar
uses unsigned checksums while creating archives, as per POSIX
standards. On reading, GNU tar
computes both checksums and accept
any. It is somewhat worrying that a lot of people may go around doing backup of
their files using faulty (or at least non-standard) software, not learning about
it until it's time to restore their missing files with an incompatible file
extractor, or vice versa.
GNU tar
compute checksums both ways, and accept any on read, so
GNU tar can read Sun tapes even with their wrong checksums. GNU tar
produces the standard checksum, however, raising incompatibilities with Sun.
That is to say, GNU tar
has not been modified to produce
incorrect archives to be read by buggy tar
's. I've been told that
more recent Sun tar
now read standard archives, so maybe Sun did a
similar patch, after all?
The story seems to be that when Sun first imported tar
sources
on their system, they recompiled it without realizing that the checksums were
computed differently, because of a change in the default signing of
char
's in their compiler. So they started computing checksums
wrongly. When they later realized their mistake, they merely decided to stay
compatible with it, and with themselves afterwards. Presumably, but I do not
really know, HP-UX has chosen that their tar
archives to be
compatible with Sun's. The current standards do not favor Sun tar
format. In any case, it now falls on the shoulders of SunOS and HP-UX users to
get a tar
able to read the good archives they receive.
gzip
. @FIXME{ach; these two bits orig from "compare" (?). where to put?} Some format parameters must be taken into consideration when modifying an archive: @FIXME{???}. Compressed archives cannot be modified.
You can use `--gzip' and `--gunzip' on physical
devices (tape drives, etc.) and remote files as well as on normal files; data to
or from such devices or remote files is reblocked by another copy of the
tar
program to enforce the specified (or default) record size. The
default compression parameters are used; if you need to override them, avoid the
--gzip (--gunzip, --ungzip, -z)
option and run gzip
explicitly. (Or set the `GZIP'
environment variable.)
The --gzip (--gunzip, --ungzip, -z) option does not work with the --multi-volume (-M) option, or with the --update (-u), --append (-r), --concatenate (--catenate, -A), or --delete operations.
It is not exact to say that GNU tar
is to work in concert with
gzip
in a way similar to zip
, say. Surely, it is
possible that tar
and gzip
be done with a single call,
like in:
$ tar cfz archive.tar.gz subdir
to save all of `subdir' into a gzip
'ed archive.
Later you can do:
$ tar xfz archive.tar.gz
to explode and unpack.
The difference is that the whole archive is compressed. With
zip
, archive members are archived individually. tar
's
method yields better compression. On the other hand, one can view the contents
of a zip
archive without having to decompress it. As for the
tar
and gzip
tandem, you need to decompress the
archive to see its contents. However, this may be done without needing disk
space, by using pipes internally:
$ tar tfz archive.tar.gz
About corrupted compressed archives: gzip
'ed
files have no redundancy, for maximum compression. The adaptive nature of the
compression scheme means that the compression tables are implicitly spread all
over the archive. If you lose a few blocks, the dynamic construction of the
compression tables becomes unsychronized, and there is little chance that you
could recover later in the archive.
There are pending suggestions for having a per-volume or per-file compression
in GNU tar
. This would allow for viewing the contents without
decompression, and for resynchronizing decompression at every volume or file, in
case of corrupted archives. Doing so, we might loose some compressibility. But
this would have make recovering easier. So, there are pros and cons. We'll see!
compress
. Otherwise like
--gzip (--gunzip, --ungzip, -z).
--compress (--uncompress, -Z) stores an
archive in compressed format. This option is useful in saving time over networks
and space in pipes, and when storage space is at a premium.
--compress (--uncompress, -Z) causes
tar
to compress when writing the archive, or to uncompress when
reading the archive.
To perform compression and uncompression on the archive, tar
runs the compress
utility. tar
uses the default
compression parameters; if you need to override them, avoid the
--compress (--uncompress, -Z) option and run
the compress
utility explicitly. It is useful to be able to call
the compress
utility from within tar
because the
compress
utility by itself cannot access remote tape drives.
The --compress (--uncompress, -Z) option
will not work in conjunction with the --multi-volume (-M)
option or the --append (-r), --update
(-u), --append (-r) and --delete
operations. See section The Five
Advanced tar
Operations, for more information on these
operations.
If there is no compress utility available, tar
will report an
error. Please note that the compress
program may
be covered by a patent, and therefore we recommend you stop using it.
tar
will compress (when
writing an archive), or uncompress (when reading an archive). Used in
conjunction with the --create (-c), --extract
(--get, -x), --list (-t) and
--compare (--diff, -d) operations. You can have archives be compressed by using the --gzip
(--gunzip, --ungzip, -z) option. This will
arrange for tar
to use the gzip
program to be used to
compress or uncompress the archive wren writing or reading it.
To use the older, obsolete, compress
program, use the
--compress (--uncompress, -Z) option. The GNU
Project recommends you not use compress
, because there is a patent
covering the algorithm it uses. You could be sued for patent infringment merely
by running compress
.
I have one question, or maybe it's a suggestion if there isn't a way to do it
now. I would like to use --gzip (--gunzip,
--ungzip, -z), but I'd also like the output to be fed
through a program like GNU ecc
(actually, right now that's
`exactly' what I'd like to use :-)), basically adding ECC
protection on top of compression. It seems as if this should be quite easy to
do, but I can't work out exactly how to go about it. Of course, I can pipe the
standard output of tar
through ecc
, but then I lose
(though I haven't started using it yet, I confess) the ability to have
tar
use rmt
for it's I/O (I think).
I think the most straightforward thing would be to let me specify a general set of filters outboard of compression (preferably ordered, so the order can be automatically reversed on input operations, and with the options they require specifiable), but beggars shouldn't be choosers and anything you decide on would be fine with me.
By the way, I like ecc
but if (as the comments say) it can't
deal with loss of block sync, I'm tempted to throw some time at adding that
capability. Supposing I were to actually do such a thing and get it (apparantly)
working, do you accept contributed changes to utilities like that? (Leigh
Clayton<EMAIL_ADDRESS>May 1995).
Isn't that exactly the role of the --use-compress-prog=program option? I never tried it myself, but I suspect you may want to write a prog script or program able to filter stdin to stdout to way you want. It should recognize the `-d' option, for when extraction is needed rather than creation.
It has been reported that if one writes compressed data (through the --gzip (--gunzip, --ungzip, -z) or --compress (--uncompress, -Z) options) to a DLT and tries to use the DLT compression mode, the data will actually get bigger and one will end up with less space on the tape.
This option causes all files to be put in the archive to be tested for
sparseness, and handled specially if they are. The --sparse
(-S) option is useful when many dbm
files, for example,
are being backed up. Using this option dramatically decreases the amount of
space needed to store such a file.
In later versions, this option may be removed, and the testing and treatment of sparse files may be done automatically with any special GNU options. For now, it is an option needing to be specified on the command line with the creation or updating of an archive.
Files in the filesystem occasionally have "holes." A hole in a file is a
section of the file's contents which was never written. The contents of a hole
read as all zeros. On many operating systems, actual disk storage is not
allocated for holes, but they are counted in the length of the file. If you
archive such a file, tar
could create an archive longer than the
original. To have tar
attempt to recognize the holes in a file, use
--sparse (-S). When you use the --sparse
(-S) option, then, for any file using less disk space than would be
expected from its length, tar
searches the file for consecutive
stretches of zeros. It then records in the archive for the file where the
consecutive stretches of zeros are, and only archives the "real contents" of the
file. On extraction (using --sparse (-S) is not needed on
extraction) any such files have hols created wherever the continuous stretches
of zeros were found. Thus, if you use --sparse (-S),
tar
archives won't take more space than the original.
A file is sparse if it contains blocks of zeros whose existence is recorded,
but that have no space allocated on disk. When you specify the
--sparse (-S) option in conjunction with the
--create (-c) operation, tar
tests all files
for sparseness while archiving. If tar
finds a file to be sparse,
it uses a sparse representation of the file in the archive. See section How to Create
Archives, for more information about creating archives.
--sparse (-S) is useful when archiving files, such as dbm files, likely to contain many nulls. This option dramatically decreases the amount of space needed to store such an archive.
Please Note: Always use --sparse (-S) when performing file system backups, to avoid archiving the expanded forms of files stored sparsely in the system.
Even if your system has no sparse files currently, some may be created in the future. If you use --sparse (-S) while making file system backups as a matter of course, you can be assured the archive will never take more space on the media than the files take on disk (otherwise, archiving a disk filled with sparse files might take hundreds of tapes). @FIXME-xref{incremental when node name is set.}
tar
ignores the --sparse (-S) option when
reading an archive.
However, users should be well aware that at archive creation time, GNU
tar
still has to read whole disk file to locate the holes,
and so, even if sparse files use little space on disk and in the archive, they
may sometimes require inordinate amount of time for reading and examining
all-zero blocks of a file. Although it works, it's painfully slow for a large
(sparse) file, even though the resulting tar archive may be small. (One user
reports that dumping a `core' file of over 400 megabytes, but with only
about 3 megabytes of actual data, took about 9 minutes on a Sun Sparstation ELC,
with full CPU utilisation.)
This reading is required in all cases and is not related to the fact the --sparse (-S) option is used or not, so by merely not using the option, you are not saving time(6).
Programs like dump
do not have to read the entire file; by
examining the file system directly, they can determine in advance exactly where
the holes are and thus avoid reading through them. The only data it need read
are the actual allocated data blocks. GNU tar
uses a more portable
and straightforward archiving approach, it would be fairly difficult that it
does otherwise. Elizabeth Zwicky writes to `comp.unix.internals', on
1990-12-10:
What I did say is that you cannot tell the difference between a hole and an equivalent number of nulls without reading raw blocks.
st_blocks
at best tells you how many holes there are; it doesn't tell you where. Just as programs may, conceivably, care whatst_blocks
is (care to name one that does?), they may also care where the holes are (I have no examples of this one either, but it's equally imaginable).I conclude from this that good archivers are not portable. One can arguably conclude that if you want a portable program, you can in good conscience restore files with as many holes as possible, since you can't get it right.
@UNREVISED
When tar
reads files, this causes them to have the access times
updated. To have tar
attempt to set the access times back to what
they were before they were read, use the --atime-preserve option.
This doesn't work for files that you don't own, unless you're root, and it
doesn't interact with incremental dumps nicely (see section Performing
Backups and Restoring Files), but it is good enough for some purposes.
Handling of file attributes
tar
leaves the modification times of the files it extracts as the
time when the files were extracted, instead of setting it to the time recorded
in the archive. This option is meaningless with --list
(-t).
tar
is
executed on those systems able to give files away. This is considered as a
security flaw by many people, at least because it makes quite difficult to
correctly account users for the disk space they occupy. Also, the
suid
or sgid
attributes of files are easily and
silently lost when files are given away. When writing an archive,
tar
writes the user id and user name separately. If it can't find
a user name (because the user id is not in `/etc/passwd'), then it
does not write one. When restoring, and doing a chmod
like when
you use --same-permissions (--preserve-permissions,
-p) (@FIXME{same-owner?}), it tries to look the name (if one was
written) up in `/etc/passwd'. If it fails, then it uses the user id
stored in the archive instead.
tar
archives. The identifying names are added at create time when
provided by the system, unless --old-archive (-o) is
used. Numeric ids could be used when moving archives between a collection of
machines using a centralized management for attribution of numeric ids to
users and groups. This is often made through using the NIS capabilities. When
making a tar
file for distribution to other sites, it is
sometimes cleaner to use a single owner for all files in the distribution, and
nicer to specify the write permission bits of the files as stored in the
archive independently of their actual value on the file system. The way to
prepare a clean distribution is usually to have some Makefile rule creating a
directory, copying all needed files in that directory, then setting ownership
and permissions as wanted (there are a lot of possible schemes), and only then
making a tar
archive out of this directory, before cleaning
everything out. Of course, we could add a lot of options to GNU
tar
for fine tuning permissions and ownership. This is not the
good way, I think. GNU tar
is already crowded with options and
moreover, the approach just explained gives you a great deal of control
already.
tar
to
set the modes (access permissions) of extracted files exactly as recorded in
the archive. If this option is not used, the current umask
setting limits the permissions on extracted files. This option is meaningless
with --list (-t).
@UNREVISED
While an archive may contain many files, the archive itself is a single
ordinary file. Like any other file, an archive file can be written to a storage
device such as a tape or disk, sent through a pipe or over a network, saved on
the active file system, or even stored in another archive. An archive file is
not easy to read or manipulate without using the tar
utility or Tar
mode in GNU Emacs.
Physically, an archive consists of a series of file entries terminated by an
end-of-archive entry, which consists of 512 zero bytes. A file entry usually
describes one of the files in the archive (an archive member), and
consists of a file header and the contents of the file. File headers contain
file names and statistics, checksum information which tar
uses to
detect file corruption, and information about file types.
Archives are permitted to have more than one member with the same member name. One way this situation can occur is if more than one version of a file has been stored in the archive. For information about adding new versions of a file to an archive, see section Updating an Archive, and to learn more about having more than one archive member with the same name, see @FIXME-xref{-backup node, when it's written}.
In addition to entries describing archive members, an archive may contain
entries which tar
itself uses to store information. See section Including a
Label in the Archive, for an example of such an archive entry.
A tar
archive file contains a series of blocks. Each block
contains BLOCKSIZE
bytes. Although this format may be thought of as
being on magnetic tape, other media are often used.
Each file archived is represented by a header block which describes the file, followed by zero or more blocks which give the contents of the file. At the end of the archive file there may be a block filled with binary zeros as an end-of-file marker. A reasonable system should write a block of zeros at the end, but must not assume that such a block exists when reading an archive.
The blocks may be blocked for physical I/O operations. Each record
of n blocks (where n is set by the
--blocking-factor=512-size (-b
512-size) option to tar
) is written with a single
`write ()' operation. On magnetic tapes, the result of such a write
is a single record. When writing an archive, the last record of blocks should be
written at the full size, with blocks after the zero block containing all zeros.
When reading an archive, a reasonable system should properly handle an archive
whose last record is shorter than the rest, or which contains garbage records
after a zero block.
The header block is defined in C as follows. In the GNU tar
distribution, this is part of file `src/tar.h':
/* GNU tar Archive Format description. */ /* If OLDGNU_COMPATIBILITY is not zero, tar produces archives which, by default, are readable by older versions of GNU tar. This can be overriden by using --posix; in this case, POSIXLY_CORRECT in environment may be set for enforcing stricter conformance. If OLDGNU_COMPATIBILITY is zero or undefined, tar will eventually produces archives which, by default, POSIX compatible; then either using --posix or defining POSIXLY_CORRECT enforces stricter conformance. This #define will disappear in a few years. FP, June 1995. */ #define OLDGNU_COMPATIBILITY 1 /*---------------------------------------------. | `tar' Header Block, from POSIX 1003.1-1990. | `---------------------------------------------*/ /* POSIX header. */ struct posix_header { /* byte offset */ char name[100]; /* 0 */ char mode[8]; /* 100 */ char uid[8]; /* 108 */ char gid[8]; /* 116 */ char size[12]; /* 124 */ char mtime[12]; /* 136 */ char chksum[8]; /* 148 */ char typeflag; /* 156 */ char linkname[100]; /* 157 */ char magic[6]; /* 257 */ char version[2]; /* 263 */ char uname[32]; /* 265 */ char gname[32]; /* 297 */ char devmajor[8]; /* 329 */ char devminor[8]; /* 337 */ char prefix[155]; /* 345 */ /* 500 */ }; #define TMAGIC "ustar" /* ustar and a null */ #define TMAGLEN 6 #define TVERSION "00" /* 00 and no null */ #define TVERSLEN 2 /* Values used in typeflag field. */ #define REGTYPE '0' /* regular file */ #define AREGTYPE '\0' /* regular file */ #define LNKTYPE '1' /* link */ #define SYMTYPE '2' /* reserved */ #define CHRTYPE '3' /* character special */ #define BLKTYPE '4' /* block special */ #define DIRTYPE '5' /* directory */ #define FIFOTYPE '6' /* FIFO special */ #define CONTTYPE '7' /* reserved */ /* Bits used in the mode field, values in octal. */ #define TSUID 04000 /* set UID on execution */ #define TSGID 02000 /* set GID on execution */ #define TSVTX 01000 /* reserved */ /* file permissions */ #define TUREAD 00400 /* read by owner */ #define TUWRITE 00200 /* write by owner */ #define TUEXEC 00100 /* execute/search by owner */ #define TGREAD 00040 /* read by group */ #define TGWRITE 00020 /* write by group */ #define TGEXEC 00010 /* execute/search by group */ #define TOREAD 00004 /* read by other */ #define TOWRITE 00002 /* write by other */ #define TOEXEC 00001 /* execute/search by other */ /*-------------------------------------. | `tar' Header Block, GNU extensions. | `-------------------------------------*/ /* In GNU tar, SYMTYPE is for to symbolic links, and CONTTYPE is for contiguous files, so maybe disobeying the `reserved' comment in POSIX header description. I suspect these were meant to be used this way, and should not have really been `reserved' in the published standards. */ /* *BEWARE* *BEWARE* *BEWARE* that the following information is still boiling, and may change. Even if the OLDGNU format description should be accurate, the so-called GNU format is not yet fully decided. It is surely meant to use only extensions allowed by POSIX, but the sketch below repeats some ugliness from the OLDGNU format, which should rather go away. Sparse files should be saved in such a way that they do *not* require two passes at archive creation time. Huge files get some POSIX fields to overflow, alternate solutions have to be sought for this. */ /* Descriptor for a single file hole. */ struct sparse { /* byte offset */ char offset[12]; /* 0 */ char numbytes[12]; /* 12 */ /* 24 */ }; /* Sparse files are not supported in POSIX ustar format. For sparse files with a POSIX header, a GNU extra header is provided which holds overall sparse information and a few sparse descriptors. When an old GNU header replaces both the POSIX header and the GNU extra header, it holds some sparse descriptors too. Whether POSIX or not, if more sparse descriptors are still needed, they are put into as many successive sparse headers as necessary. The following constants tell how many sparse descriptors fit in each kind of header able to hold them. */ #define SPARSES_IN_EXTRA_HEADER 16 #define SPARSES_IN_OLDGNU_HEADER 4 #define SPARSES_IN_SPARSE_HEADER 21 /* The GNU extra header contains some information GNU tar needs, but not foreseen in POSIX header format. It is only used after a POSIX header (and never with old GNU headers), and immediately follows this POSIX header, when typeflag is a letter rather than a digit, so signaling a GNU extension. */ struct extra_header { /* byte offset */ char atime[12]; /* 0 */ char ctime[12]; /* 12 */ char offset[12]; /* 24 */ char realsize[12]; /* 36 */ char longnames[4]; /* 48 */ char unused_pad1[68]; /* 52 */ struct sparse sp[SPARSES_IN_EXTRA_HEADER]; /* 120 */ char isextended; /* 504 */ /* 505 */ }; /* Extension header for sparse files, used immediately after the GNU extra header, and used only if all sparse information cannot fit into that extra header. There might even be many such extension headers, one after the other, until all sparse information has been recorded. */ struct sparse_header { /* byte offset */ struct sparse sp[SPARSES_IN_SPARSE_HEADER]; /* 0 */ char isextended; /* 504 */ /* 505 */ }; /* The old GNU format header conflicts with POSIX format in such a way that POSIX archives may fool old GNU tar's, and POSIX tar's might well be fooled by old GNU tar archives. An old GNU format header uses the space used by the prefix field in a POSIX header, and cumulates information normally found in a GNU extra header. With an old GNU tar header, we never see any POSIX header nor GNU extra header. Supplementary sparse headers are allowed, however. */ struct oldgnu_header { /* byte offset */ char unused_pad1[345]; /* 0 */ char atime[12]; /* 345 */ char ctime[12]; /* 357 */ char offset[12]; /* 369 */ char longnames[4]; /* 381 */ char unused_pad2; /* 385 */ struct sparse sp[SPARSES_IN_OLDGNU_HEADER]; /* 386 */ char isextended; /* 482 */ char realsize[12]; /* 483 */ /* 495 */ }; /* OLDGNU_MAGIC uses both magic and version fields, which are contiguous. Found in an archive, it indicates an old GNU header format, which will be hopefully become obsolescent. With OLDGNU_MAGIC, uname and gname are valid, though the header is not truly POSIX conforming. */ #define OLDGNU_MAGIC "ustar " /* 7 chars and a null */ /* The standards committee allows only capital A through capital Z for user-defined expansion. */ /* This is a dir entry that contains the names of files that were in the dir at the time the dump was made. */ #define GNUTYPE_DUMPDIR 'D' /* Identifies the *next* file on the tape as having a long linkname. */ #define GNUTYPE_LONGLINK 'K' /* Identifies the *next* file on the tape as having a long name. */ #define GNUTYPE_LONGNAME 'L' /* This is the continuation of a file that began on another volume. */ #define GNUTYPE_MULTIVOL 'M' /* For storing filenames that do not fit into the main header. */ #define GNUTYPE_NAMES 'N' /* This is for sparse files. */ #define GNUTYPE_SPARSE 'S' /* This file is a tape/volume header. Ignore it on extraction. */ #define GNUTYPE_VOLHDR 'V' /*--------------------------------------. | tar Header Block, overall structure. | `--------------------------------------*/ /* tar files are made in basic blocks of this size. */ #define BLOCKSIZE 512 enum archive_format { DEFAULT_FORMAT, /* format to be decided later */ V7_FORMAT, /* old V7 tar format */ OLDGNU_FORMAT, /* GNU format as per before tar 1.12 */ POSIX_FORMAT, /* restricted, pure POSIX format */ GNU_FORMAT /* POSIX format with GNU extensions */ }; union block { char buffer[BLOCKSIZE]; struct posix_header header; struct extra_header extra_header; struct oldgnu_header oldgnu_header; struct sparse_header sparse_header; }; /* End of Format description. */
All characters in header blocks are represented by using 8-bit characters in the local variant of ASCII. Each field within the structure is contiguous; that is, there is no padding used within the structure. Each character on the archive medium is stored contiguously.
Bytes representing the contents of files (after the header block of each
file) are not translated in any way and are not constrained to represent
characters in any character set. The tar
format does not
distinguish text files from binary files, and no translation of file contents is
performed.
The name
, linkname
, magic
,
uname
, and gname
are null-terminated character
strings. All other fileds are zero-filled octal numbers in ASCII. Each numeric
field of width w contains w minus 2 digits, a space, and a
null, except size
, and mtime
, which do not contain the
trailing null.
The name
field is the file name of the file, with directory
names (if any) preceding the file name, separated by slashes.
@FIXME{how big a name before field overflows?}
The mode
field provides nine bits specifying file permissions
and three bits to specify the Set UID, Set GID, and Save Text (sticky)
modes. Values for these bits are defined above. When special permissions are
required to create a file with a given mode, and the user restoring files from
the archive does not hold such permissions, the mode bit(s) specifying those
special permissions are ignored. Modes which are not supported by the operating
system restoring files from the archive will be ignored. Unsupported modes
should be faked up when creating or updating an archive; e.g. the group
permission could be copied from the other permission.
The uid
and gid
fields are the numeric user and
group ID of the file owners, respectively. If the operating system does not
support numeric user or group IDs, these fields should be ignored.
The size
field is the size of the file in bytes; linked files
are archived with this field specified as zero. @FIXME-xref{Modifiers}, in
particular the --incremental (-G) option.
The mtime
field is the modification time of the file at the time
it was archived. It is the ASCII representation of the octal value of the last
time the file was modified, represented as an integer number of seconds since
January 1, 1970, 00:00 Coordinated Universal Time.
The chksum
field is the ASCII representation of the octal value
of the simple sum of all bytes in the header block. Each 8-bit byte in the
header is added to an unsigned integer, initialized to zero, the precision of
which shall be no less than seventeen bits. When calculating the checksum, the
chksum
field is treated as if it were all blanks.
The typeflag
field specifies the type of file archived. If a
particular implementation does not recognize or permit the specified type, the
file will be extracted as if it were a regular file. As this action occurs,
tar
issues a warning to the standard error.
The atime
and ctime
fields are used in making
incremental backups; they store, respectively, the particular file's access time
and last inode-change time.
The offset
is used by the --multi-volume
(-M) option, when making a multi-volume archive. The offset is number
of bytes into the file that we need to restart at to continue the file on the
next tape, i.e., where we store the location that a continued file is continued
at.
The following fields were added to deal with sparse files. A file is
sparse if it takes in unallocated blocks which end up being represented
as zeros, i.e., no useful data. A test to see if a file is sparse is to look at
the number blocks allocated for it versus the number of characters in the file;
if there are fewer blocks allocated for the file than would normally be
allocated for a file of that size, then the file is sparse. This is the method
tar
uses to detect a sparse file, and once such a file is detected,
it is treated differently from non-sparse files.
Sparse files are often dbm
files, or other database-type files
which have data at some points and emptiness in the greater part of the file.
Such files can appear to be very large when an `ls -l' is done on
them, when in truth, there may be a very small amount of important data
contained in the file. It is thus undesirable to have tar
think
that it must back up this entire file, as great quantities of room are wasted on
empty blocks, which can lead to running out of room on a tape far earlier than
is necessary. Thus, sparse files are dealt with so that these empty blocks are
not written to the tape. Instead, what is written to the tape is a description,
of sorts, of the sparse file: where the holes are, how big the holes are, and
how much data is found at the end of the hole. This way, the file takes up
potentially far less room on the tape, and when the file is extracted later on,
it will look exactly the way it looked beforehand. The following is a
description of the fields used to handle a sparse file:
The sp
is an array of struct sparse
. Each
struct sparse
contains two 12-character strings which represent an
offset into the file and a number of bytes to be written at that offset. The
offset is absolute, and not relative to the offset in preceding array element.
The header can hold four of these struct sparse
at the moment;
if more are needed, they are not stored in the header.
The isextended
flag is set when an extended_header
is needed to deal with a file. Note that this means that this flag can only be
set when dealing with a sparse file, and it is only set in the event that the
description of the file will not fit in the alloted room for sparse structures
in the header. In other words, an extended_header is needed.
The extended_header
structure is used for sparse files which
need more sparse structures than can fit in the header. The header can fit 4
such structures; if more are needed, the flag isextended
gets set
and the next block is an extended_header
.
Each extended_header
structure contains an array of 21 sparse
structures, along with a similar isextended
flag that the header
had. There can be an indeterminate number of such extended_header
s
to describe a sparse file.
REGTYPE
AREGTYPE
tar
, a typeflag
value of
AREGTYPE
should be silently recognized as a regular file. New
archives should be created using REGTYPE
. Also, for backward
compatibility, tar
treats a regular file whose name ends with a
slash as a directory.
LNKTYPE
linkname
field with a trailing null.
SYMTYPE
linkname
field with a trailing null.
CHRTYPE
BLKTYPE
devmajor
and devminor
fields will contain the major and minor device numbers respectively. Operating
systems may map the device specifications to their own local specification, or
may ignore the entry.
DIRTYPE
name
field should end with a slash. On systems where disk
allocation is performed on a directory basis, the size
field will
contain the maximum number of bytes (which may be rounded to the nearest disk
block allocation unit) which the directory may hold. A size
field
of zero indicates no such limiting. Systems which do not support limiting in
this manner should ignore the size
field.
FIFOTYPE
CONTTYPE
A
... Z
Other values are reserved for specification in future revisions of the P1003
standard, and should not be used by any tar
program.
The magic
field indicates that this archive was output in the
P1003 archive format. If this field contains TMAGIC
, the
uname
and gname
fields will contain the ASCII
representation of the owner and group of the file respectively. If found, the
user and group IDs are used rather than the values in the uid
and
gid
fields.
For references, see ISO/IEC 9945-1:1990 or IEEE Std 1003.1-1990, pages 169-173 (section 10.1) for Archive/Interchange File Format; and IEEE Std 1003.2-1992, pages 380-388 (section 4.48) and pages 936-940 (section E.4.48) for pax - Portable archive interchange.
@UNREVISED
The GNU format uses additional file types to describe new types of files in an archive. These are listed below.
GNUTYPE_DUMPDIR
'D'
size
field
gives the total size of the associated list of files. Each file name is
preceded by either a `Y' (the file should be in this archive) or
an `N'. (The file is a directory, or is not stored in the
archive.) Each file name is terminated by a null. There is an additional null
after the last file name.
GNUTYPE_MULTIVOL
'M'
size
field gives
the maximum size of this piece of the file (assuming the volume does not end
before the file is written out). The offset
field gives the
offset from the beginning of the file where this part of the file begins. Thus
size
plus offset
should equal the original size of
the file.
GNUTYPE_SPARSE
'S'
GNUTYPE_VOLHDR
'V'
name
field contains the name
given after the
--label=archive-label (-V
archive-label) option. The size
field is zero.
Only the first file in each volume of an archive should have this type.
You may have trouble reading a GNU format archive on a non-GNU system if the
options --incremental (-G), --multi-volume
(-M), --sparse (-S), or
--label=archive-label (-V
archive-label) were used when writing the archive. In general,
if tar
does not use the GNU-added fields of the header, other
versions of tar
should be able to read the archive. Otherwise, the
tar
program will give an error, the most likely one being a
checksum error.
tar
and cpio
@UNREVISED
@FIXME{Reorganize the following material}
The cpio
archive formats, like tar
, do have maximum
pathname lengths. The binary and old ASCII formats have a max path length of
256, and the new ASCII and CRC ASCII formats have a max path length of 1024. GNU
cpio
can read and write archives with arbitrary pathname lengths,
but other cpio
implementations may crash unexplainedly trying to
read them.
tar
handles symbolic links in the form in which it comes in BSD;
cpio
doesn't handle symbolic links in the form in which it comes in
System V prior to SVR4, and some vendors may have added symlinks to their system
without enhancing cpio
to know about them. Others may have enhanced
it in a way other than the way I did it at Sun, and which was adopted by
AT&T (and which is, I think, also present in the cpio
that
Berkeley picked up from AT&T and put into a later BSD release--I think I
gave them my changes).
(SVR4 does some funny stuff with tar
; basically, its
cpio
can handle tar
format input, and write it on
output, and it probably handles symbolic links. They may not have bothered doing
anything to enhance tar
as a result.)
cpio
handles special files; traditional tar
doesn't.
tar
comes with V7, System III, System V, and BSD source;
cpio
comes only with System III, System V, and later BSD (4.3-tahoe
and later).
tar
's way of handling multiple hard links to a file can handle
file systems that support 32-bit inumbers (e.g., the BSD file system);
cpio
s way requires you to play some games (in its "binary" format,
i-numbers are only 16 bits, and in its "portable ASCII" format, they're 18
bits--it would have to play games with the "file system ID" field of the header
to make sure that the file system ID/i-number pairs of different files were
always different), and I don't know which cpio
s, if any, play those
games. Those that don't might get confused and think two files are the same file
when they're not, and make hard links between them.
tar
s way of handling multiple hard links to a file places only
one copy of the link on the tape, but the name attached to that copy is the
only one you can use to retrieve the file; cpio
s way puts
one copy for every link, but you can retrieve it using any of the names.
What type of check sum (if any) is used, and how is this calculated.
See the attached manual pages for tar
and cpio
format. tar
uses a checksum which is the sum of all the bytes in
the tar
header for a file; cpio
uses no checksum.
If anyone knows why
cpio
was made whentar
was present at the unix scene,
It wasn't. cpio
first showed up in PWB/UNIX 1.0; no
generally-available version of UNIX had tar
at the time. I don't
know whether any version that was generally available within AT&T
had tar
, or, if so, whether the people within AT&T who did
cpio
knew about it.
On restore, if there is a corruption on a tape tar
will stop at
that point, while cpio
will skip over it and try to restore the
rest of the files.
The main difference is just in the command syntax and header format.
tar
is a little more tape-oriented in that everything is blocked
to start on a record boundary.
Is there any differences between the ability to recover crashed archives between the two of them. (Is there any chance of recovering crashed archives at all.)
Theoretically it should be easier under tar
since the blocking
lets you find a header with some variation of `dd
skip=nn'. However, modern cpio
's and variations
have an option to just search for the next file header after an error with a
reasonable chance of re-syncing. However, lots of tape driver software won't
allow you to continue past a media error which should be the only reason for
getting out of sync unless a file changed sizes while you were writing the
archive.
If anyone knows why
cpio
was made whentar
was present at the unix scene, please tell me about this too.
Probably because it is more media efficient (by not blocking everything and
using only the space needed for the headers where tar
always uses
512 bytes per file header) and it knows how to archive special files.
You might want to look at the freely available alternatives. The major ones
are afio
, GNU tar
, and pax
, each of which
have their own extensions with some backwards compatibility.
Sparse files were tar
red as sparse files (which you can easily
test, because the resulting archive gets smaller, and GNU cpio
can
no longer read it).
Go to the first, previous, next, last section, table of contents.


As many other of the reports I also agree this is not a drug to get high off of. I actually threw this junk away after I tried it once or twice. I am 18 years old quit doing drugs to pass a drug test for work so I thought I would try this stuff since all the reports compared it to LSD.
I went out to my garage and packed a bowl and filled it a little over half full. I exhaled a deep breath and then lit the bowl and ripped it hard. This stuff taste so bad as if I was smoking a weed dipped in antifreeze. I held the hit in as long as I could then exhaled. About 3 seconds went by and the thought ran threw my head man I just got ripped off I don't feel nothing, and before I finished that sentence in my head I fell into a sort of trance.
 I ripped the shirt off my body confused worst than i've ever been. I was swaying back in forth I couldn't feel my body at all and I could see my garage window in a distorted view swaying back and forth. The thing that was running threw my mind was I don't know if I can get out of this. I could barely stand so I sat down on the mower in my garage.
 Freaked out I amazingly got up and started to walk up my house (keep in mind this was only like 45 seconds after I ripped the bowl). As I walked up to my house I was looking at the ground and the world was totally different. The only thing i could really remember is the ground, i was walking in the grass and i thought i could see threw the ground...the only way i can explain it is normal reality we know the world is many miles deep below us, well i thought the ground was only a few feet thick and i was about to fall threw so i was hurrying to get into my house. when i approached my deck on my house I then thought the world was going to end...like what was stopping the world from changing or ending at anytime...unlike the way we usually think and just expect and rely on everything on earth to be the same everyday.
After that I tried it a few other times to see if it would do anything different. It was the same everytime. It wouldn't be bad if it didn't make me feel all hot and make it feel like someone's pulling my face down.
Fergie
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Epic Memes from the 2010 Era
2010. oof.
very meme.
Epic Meme Vids
U R A PIRATE
Embedded straight from YouTube
bruh.
why tho
this is pretty cringe...


The Blue Cross of India was established in 1959 and registered as a Society under the Societies Registration Act in 1964 to alleviate the suffering of animals. It has grown from small beginnings to become one of India’s largest animal welfare organizations, running active animal welfare, animal rights and humane education programmes.
To ensure that all monies received by the Society are used primarily for animal welfare activities, the administration and non-medical activities of the Blue Cross of India are almost entirely looked after by members who donate their time and expertise on a purely honorary basis.
The work of the Blue Cross has received national and international recognition. Its Office Bearers have served on many State and Central Government Committees over the last forty years.


--- layout: archive-taxonomy permalink: /post-by-month/ title: "Posts by month" author_profile: true --- {% include base_path %} {% capture written_time %}'None'{% endcapture %} {% for post in site.posts %} {% capture time %}{{ post.date | date: '%Y-%m' }}{% endcapture %} {% if time != written_time %}


This weekend I headed down to Brighton with some of the London Brompton Club.
I’d offered this ride to some of my work colleagues as we did this ride last year and it was a great ride, thanks to David’s excellent navigating skills, and a couple decided to come along this weekend. I also offered it to the LBC as well, though I was aware that this would clash with the Dunwhich Dynamo that was being ridden that evening.
On the London to Whitstable ride, I made use of my Samsung S5. This let me make use of the apps on my phone, rather than my old Garmin unit for showing directions.
I sold my Garmin recently - this was partly down to the fact that I could use the Samsung for navigating and partly because I never seem to have the Garmin with me, but my phone goes everywhere.
So July is upon us already and with it some of the hottest days of the year, with temperatures reaching 36°C in places!
Anyhow, taking the idea from earlier in the year from the 30 Days of Biking challenge, I’ve decided that July that I’m going to try to and ride every day for the month. That means a tracked ride in Strava and not just the commute to work. I didn’t do it in April as I was away for business part of the time.
Today I decided to ride part of the route I’ve got planned for the LBC ride on July 25th. I’ve ridden the first section numerous times - St Albans, Hatfield and Potters Bar featured heavily on my rides over the past few years as I lived there. However, I’d never really ventured past Hertford and so the second half of the route was a complete blank to me. Not really ideal for leading a ride over in that direction!
This weekend saw the Brompton club do a tweed themed ride to celebrate a couple of members 40th birthdays (though, neither of them eventually made the ride, unfortunately). I’m not sure where the tweed part came in but it was an amusing addition to the ride!
I’ve a tweed jacket, but I ended up wearing a retro merino wool jersey that I’d got from Stolen Goat. Tweed is ok, but as we edge towards summer, I think I’d have been far far to warm.
Saturday morning is usually my lie in - its not often that my alarm will get me up at 6am in the morning on a Saturday as well as the work week! However, this weekend was different as I left Wimbledon on a train at 06:21 to get to Trafalgar Square. Why would I get up so early? Because of a bike ride!
The LBC have run a ride to Whitstable now for the last three years.
So work recently bought me an iPhone as my work phone. Whilst I’m happy with this (as much as I like Android, I find iOS to be better), it has led to a few head scratching moments.
Namely, as an Apple user for a fair amount of time, I’ve purchased a fair amount of apps on the App Store that I want to use on the work phone, but I’m hampered by the fact it’s linked to a new AppleID, one created with my work email.
A few weeks ago, I upgraded my Brompton to the puncture proof, Tannus tyres. I’ve had a puncture twice now on my Bromptons - both times occurring when I didn’t have a puncture repair kit with me (once, as I was on a quick ride around Hatfield and the other when I was commuting home from work) so I’ve been forced to walk the bike home in both instances (in fairness, I tried to get a bus home with the Brompton the last time, but the local bus service in Welwyn threw that idea out the window - the time waiting for the next bus, I’d have actually got home).
Saturday saw me do a ride with the London Brompton club. It’s the first ride I’ve done with them for quite a while to be fair due to various reasons (such as not being in the country!)
The promise of cake made the ride seem like a good prospect and the good weather we’d been having for the last few days made me think that perhaps the ride would be accompanied with good weather.
I have recently spent a few days in Ireland for a holiday, meeting my girlfriends family and friends from back home. Whilst I was there, I managed to get out and about for a quick bike ride.
I borrowed a bike from one of the family members and did a loop of the local area whilst the house was being setup for the extended family to arrive over the weekend.


An ostrich sticking its head in sand.
Home pages with ARIA present averaged 60% more errors than those without.
Source: WebAIM Million – One Year Update
The word history written in white chalk on a blackboard.
Don't use ARIA.
Unless you really, really, REALLY need to.
An owl with its head twisted upside down, looking really puzzled.
aria-role

Mama said don't be rude and interupt

Mama said don't be rude and interupt

<input aria-describedby="someid">

One thing

A different thing

aria-label
vs.
aria-labelledby
<input aria-labelledby="label1">

Some label

<input aria-label="Some label">
<input aria-describedby="SomeID">

Some text describing the input

Cannot be automatically translated!

If there's any chance of a user needing translation, the label element is better

aria-hidden
vs.
role="presentation"
<input type="text" id="FirstName">

First name can't be empty

<input type="text" id="FirstName" aria-describedby="errFirstName">

First name can't be empty

First Name *
First Name *
First Name *
<input required type="text">
vs.
<input aria-required="true" type="text">
Don't use ARIA if there's a native HTML way of doing things, right?
Nicolas Steenhout


Track and Field is a very simple but challenging sport. It requires indurance, speed, and strategy. Below are some of the sports that Track and Field includes.
The shortest event in track and field is calLed the 100 meter dash. ALl you do is run straight to the finish line. The world record the the 100 meter dash was set by Usain Bolt in 2009 with a time of 9.58
Another event in track and field is called the 400. This is a race that requires speed and indurance. It is one lap around the track. The world recored was set by Wayde van Niekerk from South Africa with a time of 43.03
Lastly Track and Field has team events such as relay races. Relay races consist of four people. Usally Jamaica and America usally have the best relay teams. Relay races can be all different sizes.
4x100
4x200
4x400
4x800
Sprint Medley
Some of the best track runners in the world are
Usain Bolt
Justin Gatlin
Allyson Felix
Shelly-Ann Fraser-Pryce
Shaunae Miller-Uibo
Tyson Gay
Sydney McLaughlin
Here is a photo of Allyson Felix and Shelly-Ann Fraser-Pryce:


var successiveFabOptionMarginPx: Float
The margin (in pixels as a positive float) between successive FabOptions in this ExpandableFab orientation. See firstFabOptionMarginPx if trying to set the margin between the first FabOption in this orientation and the ExpandableFab itself. Default value is 75f.


?6
7
8
9
10
The
new
York
copyright
reserved
botanical
Garden
Flora
of
St.
John,
U.S.
Virgin
Islands
New
York
Botanical
Garden
BOTANICAL
QARDE*L
COLL:
P.
Acevedo
Rdgz.
DATE:
3
Feb
1991
Supported
by
funds
from:
Smithsonian
Institution
and
The
Homeland
Foundation
SMITHSONIAN
INSTITUTION
From
THE
UNITED
STATES
NATIONAL
HERBARIUM
FABA
NO:
4115
Erythrina
corallodendrum
L
LOCALITY:
Cruz
Bay
Quarter;
Center
Line
Road
(Road
10),
km
2.2
HABITAT:
Along
roadside.
DESCRIPTION:
Tree,
5
m
tall;
branches
with
thorns.
Calyx
and
corolla
bright
red.
1618911
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


Malang will never dissapointed you. From every step you took you will be amazed and suddenly fallin love with Malang
Malang is the second largest city in East Java province, Indonesia. It has a history dating back to the ancient Mataram Kingdom. The city is famous for its cool temperature. People in East Java sometimes call it "Paris of East Java.
Being around by many mountain, Malang not only came with mountain vacation, but our beach, cultural spot, and Human Interest is worth to experienced.
is a city located in East Java Province of Indonesia. It is situated about 20 km to the northwest of Malang. Formerly, it was a part of Malang Regency; but in 2001, Batu became an independent city. A population of 190,000 people, it lies on the southern slopes of Gunung Welirang. Its population largely consists of Javanese.
Mount Bromo is an active volcano and part of the Tengger massif, in East Java, Indonesia. At 2,329 metres (7,641 ft) it is not the highest peak of the massif, but is the most well known
Simply drag and drop what you want to visit, and voila we make a ittinery and schedule for your vacation. have a great trip !
Your Ittinery Title Here
We Will Give you latest information about Malang


Step 1: Understand the Product
The first step is to understand the product. What is the product? A product is something that is created through a process and that provides benefits to a specific market. In our case, this could be a SaaS website or e-commerce platform for example.
Within the product you have a core, it’s the basic part that the product can’t function without. Take Uber, for example, one of the features they have is that you can see where the Uber driver is. What happens if that’s broken? The right answer is nothing, it’s a nice feature to have that builds on top of the core of the product. The core product of Uber is that you can get a driver from your specific location to somewhere else.
Everything that’s broken but isn’t related to the core product has less priority than things that are broken and are needed to keep the product going. An example of such functionality can be payment options. If payment isn’t working, your users can’t do the payment and you don’t have revenue coming in. Your users can’t buy the thing they want so they’ll leave. You might never get them back from this point. This has a direct impact on the business.
In short, think about what the core of the product is and what isn’t. This way you can start prioritizing yourself before you even contact the product owner or the development team.
Summary:
- Write down what the core of the product is
- Bugs that break the core of the product have the highest priority
- Bugs that don’t affect the core of the product have less priority
Step 2: Define the Problem (Bug)
Now you’ve learned a little about the ‘product’. The next step is what you probably often already do. You want something from the development. Let’s start with defining the problem and what the development team needs in order to reproduce the bug so they can fix it.
The first step for writing down the bug you’ve found. Do this as clearly and detailed as possible including date, time, browser, device and the URL.
Checklist:
- Explaining the problem
- Date & Time
- Browser (and size if it’s not full screen)
- Device
- URL
- Input (optional)
- Screenshot (if possible)
For example, I’ve found that the search form on our homepage isn’t working anymore. The form itself isn’t the problem but something goes wrong when I try to submit the search. I tried this on 23-03-2020 in the Chrome browser on a mobile device. This is the URL of the page: theurlhere.com. My input was the date 04-04-2020 to 06-04-2020, after selecting these days I’ve submitted the form.
Step 3: Research
You’ve written down the problem, now it’s time to research the bug. This is important because it saves development time. For example, check if this problem occurs on other pages and other domains (if you have multiple). Does this always happen, in all browsers?  Did you deactivate all ad blockers?
Besides answering the questions I mentioned you could also clarify the problem with data from Google Analytics, for example. This way you can find out the impact of the problem and define the priority. Even if the impact on the core of the product isn’t that big (highest priority) you still have lowest to high priority available to choose from. If data indicates you’re missing a lot of revenue because an upsell is broken you could give this bug high priority instead of highest.
Add the findings to your case after writing down the problem. Things like these save time for the development team since they don’t have to check and research the bug extensively anymore.
Not sure what to research? Contact the UX Designer or Product Owner in your company so they can help you out.
Step 4: Define Solution (if possible)
Not everybody is technical and that’s fine! If you can find a solution or multiple solutions for the bug already it’s nice to mention these. A really black and white solution could be to remove the functionality completely until the bug is fixed or add extra text to the place that contains the bug so users have a workaround.
Keep in mind that the development team needs time to fix bugs as well, it might in some occasions even take days before a solution can be found and added to the website. You could give them a temporary solution like for example remove a certain input field from the contact form until it’s fixed.
Example bug request
Problem
The PayPal payment option in the shopping cart checkout isn’t working anymore on 08-04-2020 around 12:19. The browser I’ve been using is Chrome on my mobile phone. This is the URL {URL HERE} to the page: and I was trying to buy the new book called Rework.
Research
I’ve checked other items that can be bought on our website and this bug occurs there as well. The other payment options seem to be working. I’ve used different browsers like Firefox and Safari to check the bug and I’ve also tried incognito mode. I couldn’t find anything on Google related to the PayPal payment option being offline at this moment.
In Google Analytics I found that this bug occurs since 07-04-2020 since no more PayPal payments came in. PayPal is our number 2 most used payment option.
Solution
It’s important that this payment option is fixed as soon as possible since it’s our second most used payment option. Until it’s fixed it would be better for the user experience to remove the PayPal payment option so our new users don’t know we have this payment option, they will probably choose another one.
Priority: Highest
Final words
Reporting a bug can be time-consuming, but it has to be done in order to get the development team working on the most important things for the business. Many people don’t understand how the SCRUM/development team is working so I hope this article gave you some clearance on that.
If you have any questions feel free to drop a comment or hit me up on LinkedIn. I’m a UX/UI/CRO specialist working remotely from the Netherlands.


Today has been a very strange day, truly one of a kind. I don't think I've felt this peaceful and content in almost two years.
It started with the events of last night. I drank almost an entire liter of wine. I was very very intoxicated. I was alone at home, but I was talking to numerous people online, both on AIM, MSN, and chat rooms. There were points when I felt I was on the verge of making an ass of myself, but I think I caught myself every time. I made a connection with someone that I previously disliked. I listened to his story and I empathized with him. It's a rare occurence nowadays for me to be able to listen to a story, and not immediately pick a side, so for me to be able to listen to this story and remain neutral, and sympathize with both parties was kind of a revelation for me. In addition, I laughed so much. I haven't laughed that much in a long time, and it was very theraputic for me. I know a lot of that had to do with the alcohol, but it was good for me regardless.
I went to sleep pretty late, and I didn't sleep well or long. I woke up around 7 am with a bad stuffy nose. I decided to try some of the mugwort I bought yesterday to see if it would calm me down enough to sleep again, and that's where the fun really began. I made a cup of tea with about an ounce of herb. It's a very fluffy, powdery feeling substance, and it has a sweet, herby smell to it. I was nervous about drinking the tea initially, I was expecting a strong, bitter flavor for some reason. The flavor was actually very nice. It tasted just like a cup of mild green tea, with a slightly bitter aftertaste now and then, but nothing lingering or unpleasant. I finished the entire cup in about 5 minutes (I'm a tea drinker, so it goes down like water for me).
After about ten minutes, I started feeling very calm and mellow. Although I had slept so little, I didn't feel tired or exhausted, I felt very relaxed, but awake. It also seemed to suppress my appetite. I had awoken with a hangover headache, and with a growling stomach. I didn't eat anything because I wanted to feel the full effects of the tea. After drinking the tea (which was at about 8 am), I had no desire to eat.
For the rest of the morning I just hung out in my room, playing around on my computer and chatting with people. Around noon, my friend came and picked me up to go to the bank. She noticed a difference in my demeanor right away. Normally when we're together we're very rowdy, loud, raunchy, and obnoxious. She commented on my relaxedness. After we went to the bank, we were both a little hungry so we stopped at Taco Bell. I was unable to eat much, I got two burritos and I was only able to eat one in the restaurant. I had no idea that mugwort was an appetite suppressant, but I'm not sure I mind it at all!
After she dropped me off at home, I decided to try smoking some of the herb. I emptied out a cigarette, and packed it with mugwort as well as I could manage. Once I lit it however, the herb burned extremely fast. The cigarette was literally gone in seconds. I'm pretty sure I didn't pack it correctly. From what I managed to inhale, the smoke was very sweet and light, it smelled similar to marijuana, only without the heavy chemical/tar smell. The taste was nonoffensive, and the smoke didn't sting or burn. Next time I'll either try rolling papers, or I'll try smoking it out of a glass bowl. I have a feeling that will work a lot better.
After I smoked (or attempted to smoke) my mugwort joint, I remained in my room. At this point, fatigue took over, and I managed to nap for a short period of time. I did have a very vivid, emotionally-charged dream. When I woke up again, I was still very relaxed, but as time wore on the thought of productivity became more and more appealing, and eventually the desire to get up and do small tasks around the house took over. It's now been over 12 hours since I first ingested the mugwort tea, and while I'm still feeling very mellow, I'm not floating quite as high as I was during the majority of the day. My appetite is slowly beginning to come back, and genuine fatigue is beginning to set in due to the lack of sleep.
Right now I'm steeping a tea bag full of mugwort in the little wine that I have left over, and I plan to drink it at about 10 pm tonight. Hopefully the outcome with be lucid and memorable dreams!
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Motorbikes collide, 1 dies, 5 hurt
by Zaida Delos ReyesA man was killed while five others, including his two sons, were wounded in a vehicular accident involving two motorcycles the other day in Coron, Palawan.
Police Regional Office (PRO) Mimaropa spokesman Police Lt. Col. Aries Faltado identified the fatality as Bernie Evangelista Macaranas, 36, married, laborer and resident of Sitio Tulawa, Barangay Guadalupe, Coron, Palawan.
Taken to Coron District Hospital were Bernie’s sons Vince , 8, and Aljur.
Also taken to the hospital were Joel Miral Amorganda, 24, driver of another motorcycle and his back-riders Arvie Amorganda Sr., 58, and Armvie Iral, 21, both residents of Barangay Sto Nino, Busuanga, Palawan.
Reports reaching Camp Crame said that the accident occurred at around 5:20 p.m. along the national highway of Sitio Carmelita, Barangay Guadalupe, Coron, Palawan.
Initial investigation showed that Bernie Macaranas was driving his Rusi motorcycle with his two sons as back-riders on their way home when they collided head-on with another motorcycle driven by Joel Amorganda with his father and brother as back-riders.
The report said Macaranas was driving too fast, encroached the opposite lane and collided with the SYM motorcycle of Amorganda.
Because of the strong impact, Macaranas died on the spot while his sons sustained injuries.
The Amorgandas also sustained severe injuries and were taken to the hospital.


METASPLOIT
use auxiliary/scanner/http/backup_file
use auxiliary/scanner/http/cert
use auxiliary/scanner/http/dir_listing
use auxiliary/scanner/http/dir_scanner
use auxiliary/scanner/http/host_header_injection
use auxiliary/scanner/http/http_header
use auxiliary/scanner/http/http_hsts
use auxiliary/scanner/http/http_put
use auxiliary/scanner/http/http_traversal
use auxiliary/scanner/http/http_version
use auxiliary/scanner/http/ms15_034_http_sys_memory_dump
use auxiliary/scanner/http/nginx_source_disclosure
use auxiliary/scanner/http/options
use auxiliary/scanner/http/robots_txt


--- layout: default title: Neat Starter path: home ---
NEAT Starter Template. Get Started by editing. /index.njk
/index.njk


ALLERGY PLUS SINUS HEADACHE- acetaminophen, diphenhydramine hydrochloride and phenylephrine hydrochloride tablet
GREENBRIER INTERNATIONAL, INC.
Disclaimer: Most OTC drugs are not reviewed and approved by FDA, however they may be marketed if they comply with applicable regulations and policies. FDA has not evaluated whether this product complies.
Active ingredients (in each caplet)
Acetaminophen 325 mg
Diphenhydramine HCl 12.5 mg
Phenylephrine HCl 5 mg
Purpose
Pain reliever
Antihistamine
Nasal decongestant
Uses
- temporarily relieves these symptoms of hay fever and the common cold:
- runny nose
- sneezing
- headache
- minor aches and pains
- nasal congestion
- temporarily relieves these additional symptoms of hay fever:
- itching of the nose or throat
- itchy, watery eyes
Warnings
Liver warning: This product contains acetaminophen. The maximum daily dose of this product is 10 caplets (3,250 mg acetaminophen) in 24 hours. Severe liver damage may occur if you take:
- more than 4,000 mg of acetaminophen in 24 hours
- 3 or more alcoholic drinks every day while using this product
- with other drugs containing acetaminophen
Do not use
- with any other drug containing acetaminophen (prescription or nonprescription). If you are not sure whether a drug contains acetaminophen, ask a doctor or pharmacist.
- with any other product containing diphenhydramine, even one used on skin
- if you are now taking a prescription monoamine oxidase inhibitor (MAOI) (certain drugs for depression, psychiatric or emotional conditions, or Parkinson's disease), or for 2 weeks after stopping the MAOI drug. If you do not know if your prescription drug contains an MAOI, ask a doctor or pharmacist before taking this product.
- if you have ever had an allergic reaction to this product or any of its ingredients
Ask a doctor before use if you have
- liver disease
- glaucoma
- thyroid disease
- heart disease
- diabetes
- high blood pressure
- difficulty in urination due to enlargement of the prostate gland
- a breathing problem such as emphysema or chronic bronchitis
Ask a doctor or pharmacist before use if you are
- taking the blood thinning drug warfarin
- taking sedatives or tranquilizers
When using this product
- do not exceed recommended dosage
- avoid alcoholic beverages
- may cause drowsiness
- use caution when driving a motor vehicle or operating machinery
- excitability may occur, especially in children
- alcohol, sedatives, and tranquilizers may increase drowsiness
Stop use and ask a doctor if
- nervousness, dizziness, or sleeplessness occur
- pain or nasal congestion gets worse or lasts more than 7 days
- new symptoms occur
- fever gets worse or lasts more than 3 days
- redness or swelling is present
If pregnant or breast-feeding,
ask a health professional before use.
Keep out of reach of children.
In case of overdose, get medical help or contact a Poison Control Center (1-800-222-1222) right away.
Directions
- do not use more than directed
- adults and children 12 years and over
- take 2 tablets every 4 hours
- do not take more than 10 caplets in 24 hours
- children under 12 years: ask a doctor
Other information
-
TAMPER EVIDENT: DO NOT USE IF OUTER PACKAGE IS OPENED OR BLISTER IS TORN OR BROKEN
- store at 25ºC (77ºF); excursions permitted between 15º-30ºC (59º-86ºF)
- see end flap for expiration date and lot number
Inactive ingredients
corn starch, croscarmellose sodium, crospovidone, D&C yellow #10 aluminum lake, FD&C blue #1 aluminum lake, FD&C red #40 aluminum lake, magnesium stearate, microcrystalline cellulose, polyethylene glycol, polyvinyl alcohol, povidone, silica gel, stearic acid, talc, titanium dioxide
Questions or comments?
1-800-426-9391
Principal Display Panel
ASSURED™
COMPARE TO ACTIVE INGREDIENTS OF
BENADRYL® ALLERGY PLUS SINUS HEADACHE*
MULTI-SYMPTOM
ALLERGY
PLUS SINUS HEADACHE
• Acetaminophen - Pain Reliever
• Diphenhydramine HCl - Antihistamine
• Phenylephrine HCl - Nasal Decongestant
Headache, Sneezing, Itchy & Watery Eyes,
Runny Nose, Itchy Throat,
Sinus Congestion & Pressure
Actual Size
12 caplets
*This product is not manufactured or distributed by McNeil Consumer Healthcare, owner of the registered trademark Benadryl® Allergy Plus Sinus Headache.
50844 REV0115C46402
ITEM# 163821
Distributed by: Greenbrier International, Inc.
Chesapeake, VA 23320 USA
TAMPER EVIDENT: DO NOT USE IF PACKAGE IS OPENED OR IF BLISTER UNIT IS TORN, BROKEN OR SHOWS ANY SIGNS OF TAMPERING
Assured 44-464
GREENBRIER INTERNATIONAL, INC.


--- layout: page title: Refactoring date: 2013-02-19 01:50:46.000000000 +01:00 categories: [] tags: [] status: draft type: page published: false meta: _edit_last: '45897461' _sd_is_markdown: '1' _wp_page_template: page-right.php original_post_id: '166' _wp_old_slug: '166' author: login: breitzammer email<EMAIL_ADDRESS>display_name: breitzammer first_name: '' last_name: '' ---
Do you ever find yourself in the situation when:
* Adding new features is very slow because of the existing code?
* Developers complain about architecture and design issues?
* Your teams ask for one month (or more) to refactor the code?
Then it is time to learn how to do refactoring correctly.
At the end of this workshop, you will know how to:
You will learn all this, by doing lots of practical exercises, all under the supervision of a very experienced refactorer:
Basic code refactoring techniques
Refactor in baby steps
How to effectively use your IDE for refactoring (only applies to Visual Studio, Visual Studio + ReSharper, Eclipse or IntelliJ Idea. It might apply to other tools who have similar refactoring features.)


Erin Brockovich (2000) Reviewed by Eugene Novikov http://www.ultimate-movie.com/ Member: Online Film Critics Society
Starring Julia Roberts, Albert Finney, Aaron Eckhart. Directed by Steven Soderbergh. Rated R.
Even if the movie itself is a bit lackluster, Erin Brockovich will stick in my mind as one of exceedingly few movies where Julia Roberts doesn't play Julia Roberts. It hasn't happened since 1997's wonderful Conspiracy Theory. Everywhere else, she's played the same role, the unsure-of-what-she-wants romantic role model. She has a distinctive romantic relationship here too, but at least she gets to spout some entertainingly fiery monologues while she's at it. Too bad the movie gets bogged down in a trite legal plot rather than explore her interesting character further.
The title character is a twice-divorced, uneducated, unemployed woman, taking care of three young children while trying to keep herself from starving. She's desperately running all around L.A. looking for a job -- something, anything -- but is turned down everywhere she goes because of her lack of schooling and expertise. But finally, via a string of good luck (and perseverance), Erin gets a position as a clerk in a small law firm.
Her boss, an elderly lawyer named Ed Masry played by the inimitable Albert Finney, is often taken aback by Erin's overtly aggressive nature.  But then she goes off on a tangent, to investigate a real estate case that, for some reason, has bloodwork and medical records mixed in. She soon finds that an evil utility company named "PG&E" is contaminating a town's drinking water with inordinate amounts of hexavalent chromium, a poisonous, carcinogenic substance that's not supposed to be in tap water under any circumstances.
Needless to say, all of the town's residents are seriously affected, with medical bills starting to skyrocket. So Erin, the gentle soul that she is, convinces her boss to take on this giant class-action suit, which may be a serious risk for good old Ed, since it requires a lot of time and money but does not guarantee a positive outcome. Meanwhile, Erin herself developed a relationship with an unusually kindly, unemployed biker dude (Aaron Eckhart) who takes care of her kids when she's at work, but the arrangement is on thin ice because she is hardly ever home anymore...
The first half if this movie jumps off the screen at you. Julia Roberts is riveting as a street-smart, desperate woman struggling to survive in a big city. Her story is interesting, compulsively watchable. Immediately, she seems like a woman I'd love to spend the next two and a half hours with. This blissful state continues for a half an hour or so. But director Steven Soderbergh and writer Susannah Grant aren't at all interested in keeping it that way. It's downhill from there.
The turning point, of course, is when the characters get mixed up in the legal matter. This shifts Erin Bronkovich's focus -- how could it not -- and it becomes a moderately entertaining but painfully ordinary Grishamesque legal drama. The movie manages to pause and actually examine what's happening to this person I got so attached to in the first half hour precious few times. Hexavalent chromium has completely taken over and the film isn't as interesting anymore.
Ironically, though the lawsuit plot takes up most of Erin Bronkovich's running time, it seems almost like an afterthought, something put in to entertain the lowest common denominator because the masses presumably wouldn't be interested in just the person (what destroys this argument is that the film is actually a true story, but for cinematic purposes I'm going to cheerfully ignore that fact). It's a shame that a personality so decidedly unique had to be diluted with a storyline so trite.
What really pulls you through it, in the end, is the performances. Julia Roberts remains tremendously entertaining, spouting harsh, loud monologues right up until the credits. Few can outshout Roberts. Albert Finney, a four-time Oscar nominee steals a lot of the scenes he is in. He has the perfect combination of grumpiness and amiability that's often difficult to concoct. It helps that he is given some downright hilarious lines.
Those who watch Erin Brockovich might remember last year's terrific John Travolta drama A Civil Action, which was also about a lawyer helping a town with poisoned water. The difference betwene the two was that in Civil Action, the legal matter was its driving force. It was the centerpiece and the rest of the plot revolved around it. The trouble with Erin Brockovich is that the character is the centerpiece and the lawsuit takes our attention away from it.
Grade: C+
©2000 Eugene Novikov
Sent via Deja.com http://www.deja.com/ Before you buy.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


One-in-five young people suffer extreme anxiety - survey
More than one in five adolescents suffer from severe anxiety, it has emerged.
The number of adolescents aged between 12 and 19, reporting severe anxiety doubled from 11% to 22%.
Levels of severe anxiety in young adults (18-25 years) increased from 15% to 26% - an 11% increase.
The significant increase in anxiety since 2012 is reported in My World Survey 2, a major study on youth mental health.
The proportion of adolescents who fell into the severe and very severe categories for depression increased from 8% to 15%.
Young adults with severe and very severe depression had also increased – from 14% to 21%.
Young adults (33%) were also more likely to report that they deliberately hurt themselves without wanting to take their own life than those in the earlier survey (22%).
About two-thirds had thought about taking their life but “would not do it”. Sadly, one in ten had made a suicide attempt.
It emerged that males had significantly higher self-esteem, optimism and life satisfaction than females.
Also when adolescents were faced with problems, 60% talked about them with someone.
Females (63%) were more likely than males (56%) to talk to someone about their problems.
Over 19,000 young people were consulted for the follow-up and extension of the 2012 My World Study 1.
There was a decrease from 45% to 39% in the proportion of adolescents being bullied and those who had ever consumed alcohol had fallen from 51% to 42%.
One in ten young adults did not drink alcohol, 42% drank alcohol every week and 2% daily or almost daily.
Of those who drank, 7% were at risk of harm and 6% were classified as having possible alcohol dependence.
More than half (53%) of young adults had smoked cannabis and 40% had used drugs other than those needed for medical reasons.
The comprehensive study of young people's mental health was developed by Jigsaw, the National Centre for Youth Mental Health, and the University College Dublin's School of Psychology.
Chief executive of Jigsaw, Dr Joseph Duffy, said the study indicated that more needs to be done to address the main issues affecting young people.
“The increased levels of anxiety and depression, the decreased levels of self-esteem, optimism and life-satisfaction and growing trends of self-harm are of particular concern,” said Dr Duffy.
A member of Jigsaw's youth advisory panel, Rachel White, said the report must be the start of a new and honest conversation about what it is to be young in Ireland.
While there were some positives the report was, in the main, a wake-up call, said Ms White
The question we should really be asking ourselves is are we ready as a nation to step up and take up collective responsibility for our young people's mental health and the answer should be, and must be, a loud and emphatic yes.
She was glad, however, that social media was not the “demon” that some people would have them believe.
“Young people are predominantly using social media to enhance and continue friendships and relationships that they made offline,” she pointed out.
READ MORE
Brothers have home repossessed after making just two repayments on €650k mortgage


{% extends 'base.html' %} {% block content %}
Thank you for being able to log-in!


Reads Tecplot data files. Tecplot is a commercial visualization tool from AMTEC. This reader supports ASCII and Binary files from Tecplot.
Parameters
ReadTecplotParams
Name Type Description UI Control filename string Name of the Tecplot file to read. File Dialog Output Ports
Name Type Description out_mblock Multi_Block Multi_Block data which can contain several meshes read from the Tecplot file. out_fields Mesh_Struct+Node_Data [] Array of Structured meshes which are the parts of the Multi_Block.
This moddule reads the Tecplot data format. Tecplot is a commercial visualization tool from AMTEC. This reader supports ASCII and Binary files from Tecplot. The data is stored in a Multi_Block data structure and a reference to the fields array is provided. This fields array can be used with the Array of fields (*_ARR) visualization modules provided by AVS/Express.
filename
String parameter that specifies which Tecplot file should be read. The filename string should contain the full path name of the file and can contain any of the AVS/Express environment variables (e.g. $XP_PATH<1>)
out_mblock
Multi_Block data output that contains the geometries and attached data values which are contained in several blocks in the Tecplot file. The output consists of Blocks of fields containing the nodal coordinates, connectivity information and the data values per node.
out_fields
Array of Structured mesh + Node data fields that contain the geometry and attached data values read from the Tecplot file. Each of the output fields in this array consists of the nodal coordinates, connectivity information and the data values per node.
The ReadTecplotFunc functional macro uses the low-level ReadTecplotCore module. The macro takes as input the parameter blocks, ReadTecplotParams. The macro outputs the data read from the Tecplot file as Multi_Block data.
The ReadTecplotFunc functional macro and the ReadTecplotUI user interface macro are both used by the ReadTecplot user macro. All of these macros use the ReadTecplotParams parameter block to communicate. Additional to the Multi_Block output the ReadTecplot user macro has an output for an Array of Structured mesh + Node data which can be used with modules of the ARR DefaultObjects which can directly be rendered by the standard data viewers.
The project includes an example application that demonstrates the use of the ReadTecplot macro. The ReadTecplotEg application uses the ReadTecplot macro to read a Tecplot file. The Example contains an isosurface_ARR, isoline_ARR and a bounds_ARR module to show the inner structure of the fields array which is read by the ReadTecplot macro.
xp_comm_proj/rd_tecpl/rdtpmods.v contains the V definitions of the ReadTecplotCore module and the ReadTecplotParams parameter block.
xp_comm_proj/rd_tecpl/rdtpmacs.v contains the V definitions of the ReadTecplotUI UI macro, the ReadTecplotFunc functional macro and the ReadTecplot user macro.
xp_comm_proj/rd_tecpl/rdtpapps.v contains the V definitions of the ReadTecplotEg example application.
The low-level ReadTecplotMods library containing the low-level module ReadTecplotCore does not specify a process. By default the express process will be used.
I. Hallstein, Dr. Tomas Forkert DLR - Deutsches Zentrum fuer Luft- und Raumfahrt e. V. Simulations- und Softwaretechnik (SISTEC) Contact:Dr. Tomas Forkert DLR - Deutsches Zentrum fuer Luft- und Raumfahrt e. V. Simulations- und Softwaretechnik (SISTEC) D-51140 Koeln e-mail<EMAIL_ADDRESS>voice: ++49 2203 601 2066 fax: ++49 2203 601 3070 http://www.sistec.dlr.de
Tobias Schiebeck, International AVS Centre


I have been using the pomodoro system
I been pleasantly surprised about how it worked to be honest. I hope that doesn't sound cynical but I've always worked jobs where asking for a break was tantamount to heresy.
I find pomodoro to work really well, and I need it.
I will look at any and all new techniques, maybe you need to take a break from pomodoro too? oooh too soon ... ? Time boxing is going to be a major for me so I'm all ears for suggestions that work for others. Fogg also sounds interesting with the tiny habits as I'm usually slow to form habits, but once done I am locked down.


The motivation and technology for our hack.
Athletes care about the weather
The purpose of this web site is to assist athletes as they prepare for their upcoming training by checking the daily weather and air quality.
Based on the temperature, air quality and precipitation the website provides custom feedback that includes motivational messages aligned to the weather and air quality conditions.
Provide the capability to integrate this web site with training products like Garmin, Strava, and TrainingPeaks to further focus on the athletes specific training activities
Over time identify correlations between weather and training performance
Provide the capability to allow users to register and get daily updates
Provide the capability to access the application through mobile devices
Move quotes from files into a database
Evaluate historical performance against weather metrics to provides new training insights
The chart above shows the athlete has a temperature range sweet spot (i.e., between 50 and 80 degrees) for longer run distances.
The chart above shows calculated historical average temperatures aligned to running data time period.
The splash page has a word cloud image created in R that mines twitter using the hash tags; #swim, #run, and #bike.
The web application was written in python and flask and is located at twcHack
The image shows structure of the flask applicationThis function calls AirNow's Zip Forecast to get current or historical forecasted air quality index (AQI) values and categories for a reporting area by Zip code.
Flask is a micro web framework written in Python and based on the Werkzeug toolkit and Jinja2 template engine. It is BSD licensed.
Motivator takes output from airQuality.py, tendayForecast.py and quotes.py and customizes a user's weather report based on the air quality and weather features.
Provides customized quotes based on temperature, air quality, and precipitation.
This function calls the weather API and based on the zip code provided by the user brings back weather information. Documentation for the API can be found at Weather Company Data for IBM Bluemix
This function takes a zip code input from the web application index.html page and returns a latitude and longitude used by other functions.


Data
public struct Data
Keyboard notification’s userInfo
parsed object
-
UIKeyboardFrameBeginUserInfoKey
andUIKeyboardFrameEndUserInfoKey
notification’s valuesDeclaration
Swift
public var frame: Frame
-
UIKeyboardAnimationCurveUserInfoKey
notification’s valueDeclaration
Swift
public var animationCurve: Int
-
UIKeyboardAnimationDurationUserInfoKey
notification’s valueDeclaration
Swift
public var animationDuration: Double
-
UIKeyboardIsLocalUserInfoKey
notification’s valueDeclaration
Swift
public var isLocal: Bool


~Your Pizza~
The Cheapest Pizza in Town!
Meat (2ea):
Pepperoni
Grilled Chicken
Sausage
Veggie (1ea):
Pineapple
Spinach
Mushrooms
Size:
Small
Medium
Large
Submit
Thank you for your order.


Start a new hotfix:
Development of new hotfixes start from the "master" branch.
Optionally can be started from a [base] branch. More on that later.
git flow hotfix start [version] [base]
Work on your hotfix:
Work on your hotfix, and create one or more commits.
git add .
git commit -am "That is MUCH less broken."
Finish your hotfix:
Finish your hotfix. This action:
- Merges your hotfix into develop.
- Merges your hotfix into master.
- Tags the master branch with your [version].
git flow hotfix finish [version]
git push
git push --tags


Allows to configure an optional delay (in seconds) applied after any call to cleartool endview -server command. It applies only to snapshot views.
For more details, please read the thread about this specific issue.