When you work with relatively small SQL databases, the runtime of queries may not an important issue. But as soon as tables grow in size and queries get more complex, performance may become a critical element to consider when designing your database.
Indexes are the best way to improve the runtime of SELECT
operations.
An index consists of an efficient data structure whose entries act like pointers to the table rows,
allowing a query to quickly determine which rows match a condition in the WHERE clause, and retrieve the
other column values for those rows.
In MySQL, all data types can be indexed, and the data structure used for an index depends on the type of the column.
=
, <
, <=
, LIKE
or BETWEEN
.
This means that indexes can significantly speed up queries involving a variety of constructs:
WHERE
, JOIN
, MIN()
and MAX()
, ORDER BY
, and GROUP
BY
.
To understand the impact of introducing an index on the performance of a simple query, let's consider the following example.
SELECT COUNT(*) FROM mytable WHERE mycol = 222;
If mytable
has a large number of rows n,
it is clear that the runtime of even such a simple query can become very high.
Advantages
SELECT
statements can be significantly accelerated.Drawbacks
INSERT
, UPDATE
, DELETE
statements can be slower.The easiest way to create an index on a column is to do so at the time the table is created.
CREATE TABLE my_table (
my_id INT PRIMARY KEY,
col1 INT,
col2 VARCHAR(10),
INDEX my_idx(col1)
);
However it also possible to create an index once the table already exists.
CREATE INDEX my_idx ON my_table(col1);
In many cases creating an index after the data is inserted is more efficient, to the point that
it is often recommended to DROP INDEX
before a bulk import and then re-create it after that.
This is due to the fact that the B-tree of the index needs to remain balanced so INSERT
has
a O(log n) cost.
It is important to notice that MySQL automatically creates in certain cases.
PRIMARY KEY
.FOREIGN KEY
.(col1, ...)
, then MySQL creates instead an index that also includes the primary key at
the
end:
(col1, ..., pk)
Indexes can be created on more than one column at the same time. This can be particularly useful for queries that test all columns in the index, or the first q columns in the index (for any q). In particular, when all the the the columns referenced by a query are already in the index, we say that we have a covering index and MySQL will run very fast as it just needs to read the content of the index without even needing to follow the pointers to the table rows!
For instance, let us consider the following table.
CREATE TABLE phone_book (
last_name VARCHAR(32),
first_name VARCHAR(32),
phone_number CHAR(10),
address VARCHAR(64)
INDEX my_idx(last_name, first_name, phone_number)
The index my_idx
accelerates the following two queries, but for the second one it is not
covering
(because address
is not in the index).
SELECT last_name, first_name
FROM phone_book
WHERE last_name <=> "Doe"
AND first_name LIKE "Ann%" # -- Equivalently: first_name BETWEEN "Ann" AND "Anp";
SELECT first_name, last_name, address
FROM phone_book
WHERE last_name = "Smith";
On the other hand, the following query cannot use the index, as the columns involved in the WHERE
must be the first Q columns of the index, for some Q.
Think of a real phone book, indexed by last name and then first name: if you search for numbers relative
to a
given
family name the book will be very useful, but if you look for first names you will have to scan the whole
book.
So we see that
the order of the columns in the multiple-columns indexes we create is very important.
SELECT last_name, first_name
FROM my_table
WHERE first_name = "Alice"
AND phone_number LIKE "076%"l
Also the following query cannot use the index, because it searches on the first (Q
=1)
column of the index, but a
leading
wildcard %
cannot be
translated into any range or equality clause.
SELECT *
FROM my_table
WHERE last_name LIKE "%son";
FULLTEXT
, UNIQUE
, SPATIAL
When we CREATE INDEX
, we can optionally specify an attribute between CREATE
and INDEX
: MySQL supports FULLTEXT
, UNIQUE
, SPATIAL
.
There is not much to say about SPATIAL INDEX
, other than it is used for indexing
columns with spatial data type such as POINT
and GEOMETRY
. Since this kind
of data represents coordinates, it cannot be sorted by a simple order. For this reason
B-trees
cannot
be used, and instead MySQL uses R-trees, which group nearby points and represent
them using their
minimum bounding rectangle (R in R-trees stays for rectangle).
A UNIQUE INDEX
is also easy to understand. It is just a regular index with the extra
UNIQUE
constraint on the values of the affected column or columns.
For some queries, having a unique index allows MySQL to make some optimizations and achieve better
performance than it would obtain with an ordinary index. For instance, if we execute SELECT
DISTINCT
on columns that are covered by the unique index, MySQL is able to skip the sorting and
duplicates removal stages.
The FULLTEXT INDEX
is probably the most interesting one, and it is used for full-text searches. We have already
seen that ordinary indexes can also be created on text columns like CHAR
, VARCHAR
, and TEXT
. However, such indexes are quite limited as they can only be used to
search for exact match (e.g. last_name = "Smith"
) or initial substrings (e.g.
first_name LIKE "Ann%"
). Their use case is therefore mainly limited to text columns
where each entry consists of one or a couple of words (e.g. names).
However, for many use cases a text column can contain long texts, such as the whole text of a blog
post or the whole text of a scientific paper. In this cases, we may want to retrieve all entries
where a certain term, e.g. "cat"
appears in the text. We could do this with
SELECT * WHERE text_col LIKE "%cat%";
but in this case the index would not be used, as we saw, and a full table scan would be executed.
The solution is to use a FULLTEXT INDEX
, which supports a variety of full-text
searches
such as the following.
"cat"
occurs."dog"
or "cat"
occur."dog"
and "cat"
occur."dog"
occurs but "cat"
does not occur."cat"
(e.g. cat
,
cats
,
cattle
, ...) occurs.
FULLTEXT INDEX
on text_col
, we can run all of these full-text
searches using the following clause instead of text_col LIKE expr
.
MATCH text_col AGAINST (expr [mode])
Here mode
can be one of the two following.
IN NATURAL LANGUAGE MODE
: uses tf-idf to search
a corpus.
IN BOOLEAN MODE
: define terms to be included, excluded, and other combinations.MATCH(text_col) AGAINST ("cat" IN BOOLEAN MODE) # 1.
MATCH(text_col) AGAINST ("cat dog" IN BOOLEAN MODE) # 2.
MATCH(text_col) AGAINST ("+cat +dog" IN BOOLEAN MODE) # 3.
MATCH(text_col) AGAINST ("-cat +dog" IN BOOLEAN MODE) # 4.
MATCH(text_col) AGAINST ("cat*" IN BOOLEAN MODE) # 5.
In terms of implementation, for FULLTEXT INDEX
MySQL uses an
inverted index . Inverted indexes store a list of words, and for each word, the list of
documents
where
that word appears. To support proximity search, position information for each word is also stored, as a
byte offset.
A clustered index is an index where the elements are sorted in the same way that they are physically stored in the table. A non-clustered index has a structure separate from the data rows and uses pointers to link sorted entries in the index data structure to their actual position in the table, which might not be the same that the entry has in the index.
Clearly, clustered indexes allow to skip one level of indirection (the lookup from the index data structure to the actual table). Therefore, accessing rows by a clustered index is extremely fast because the index search leads directly to the page with all the row data.
However, by construction, no more than one clustered index can exist for a table. Otherwise the table would need to be physically sorted at the same time by different columns.
InnoDB stores directly all the fields of each record into the clustered index. This makes the accesses to any of the fields of table particularly efficient whenever we query columns covered by the clustered index.
Moreover, InnoDB guarantees that each table has a clustered index. The following criterion is used, in order of priority.
UNIQUE INDEX
and all its cols are NOT NULL
, the first such
index
is clustered.
GEN_CLUST_INDEX
clustered index that increases
monotonically as new rows are inserted, so order is same as insertion into the table.
SELECT
operations.INSERT
/UPDATE
/DELETE
, disk
space, ...
FULLTEXT INDEX
, and query using MATCH
...
AGAINST
instead of LIKE
.


For Container ports and the port for the service that you want to expose to
outside world
Container Port
Expose
Service Port
Exposed Port Number
Port Name
ClusterIP To expose sevice internally within the
cluster.exposes the service on a
It makes the service accessible from within the cluster only.
NodePort This Exposes the service on each Node's IP with a
random portand the port used
to access the service will be generated in the range of 30000's eg 34212
Cloud Provider OnlyLoadBalancer
This exposes the service
externally using a cloud provider's load balancer and provide with an
External IP


--- layout: default sitemap: priority: '0.9' changefreq: 'always' ---
Hello there, and welcome to my homepage!
My name is Hongshen Chen (陈宏申), and I am NLP lead for JD.com recommendation platform, and a research scientist with Data Science Lab, JD.com. I also serve as a Youth Committee of CCF TCCI (Technical Committee of Chinese Information, China Computer Federation). I received my Ph.D. from NLP Group, Institute of Computing Technology, Chinese Academy of Sciences, advised by Prof. Qun Liu. Prior to that, I received my B.E. from Sichuan University in 2012 and worked as a short-term research assistant at Singapore University of Technology and Design with Prof. Yue Zhang , 2016. Currently, I am focusing on natural language processing, dialogue systems, machine translation, sequence labelling, etc.
I won best paper award on CCL 2016,
and received the second prize of Wu Wenjun's artificial intelligence science and technology progress, Chinese society of artificial intelligence, 2022.
I maintain a list of my publications under the Publications tab, and a list of projects under the Projects tab. You may also check out my Google Scholar profile.
To get in touch with me, kindly drop me an E-mail: ac#chenhongshen.com (#-->@).


Sharing configuration in multi-site and multi-profile
platforms: A Modern Odyssey
David López / @akalam
Ricardo Sanz / @sanzante
#DrupalDevDays
Drupal 8.6
Starting point
Starting point
Drupal 8.6
- It allows to install a site from an existent
configuration.
- This is not a default configuration but a site
configuration that's applied when a cim is done.
- Initially for development purposes:
-
1613424 - [META] Allow a site to be installed from
existing configuration
Install from existent configuration
How to
- Place configuration in configuration directory
path.
You can set your own directory if you want:
$config_directories[CONFIG_SYNC_DIRECTORY] = '/path/to/configuration';
- Install:
Install from existent configuration
Demo!
Install from existent configuration
Limitations
- Profile can't use hook_install*
- Only applicable for one site (or exact clones,
because configuration is the same).
Install from existent configuration
Use
- Set up a site in certain environments (local,
CI).
- It doesn't include content (advantage or
drawback?).
- Allows to create installation profiles easily.
Just that?
Let's extend it!
What we want
Family of sites
Family of sites
What if we …?
- …use installation profiles to get types of sites
easily installed from an existent configuration?
- …use mechanisms to customize each site's
configuration?
- …try to reuse configuration in a family of
sites?
Family of sites
Examples
- Group of corporate websites.
- Family of similar but different media publishing
websites.
- SaaS website for building specific types of
websites.
- World wide organization with sites per country,
region and/or events.
- …
Graphic example
Corporation
Family of sites
What and how from a Drupal perspective
Family of sites
What
Family of sites
What
- Set of installation profiles sharing a common
conf.
- Installation profiles can customize the conf.
- Use inheritance to create a hierarchy of installation
profiles.
- Sites can customize their configuration as well.
- Ability to enable a module that provides a complete
functionality to site (Features style).
- In one line: we reuse code, let's reuse
configuration.
Family of sites
How
- Sites are installed from installation profiles and
get its config from the existent configuration.
- The existent configuration (yml files) is shared by
installation profiles.
- Use installation profile inheritance to extend parent
profiles.
-
Config
Filter, Config
Split and
Configuration Override System to customize sites's
configuration based on different conditions.
Family of sites
Hands-on!
Hands-on
What we need
- Automatically apply existent configuration on install
profile installation.
- Install profile inheritance.
- Installation profiles that share a common
configuration.
- Enable custom site's configuration on certain
conditions.
Hands-on
1.- Installation profiles using existent
configuration
1.- Installation profiles using existent
configuration
What is?
- What Drupal 8.6 does, but just selecting an
installation profile.
- Site is installed using existent configuration.
- First implemented in Config installer installation
profile.
1.- Install from existent configuration
How to
1.- Installation profiles using existent
configuration
How to
- existing-config parameter needs to be
automatically enabled.
- Enabled from installation profile code.
- Implement hook_install_tasks_alter() on
MY_PROFILE.profile.
Requisite: Apply conf on profile installation
How to
/* Implements hook_install_tasks_alter(). */
function MY_PROF_install_tasks_alter(&$tasks, $install_state) {
_MY_PROFILE_install_tasks_alter($tasks, $install_state);
}
function _MY_PROFILE_install_tasks_alter(&$tasks, $install_state) {
// Use the Drupal 8.6 way of importing from existing conf.
if (!$install_state['parameters']['existing_config']) {
// @codingStandardsIgnoreLine
global $install_state;
$install_state['parameters']['existing_config'] = TRUE;
}
}
Tested on 8.6 and 8.7.
Hands-on
2.- Installation profile inheritance
Requisite: Installation profile inheritance
What is?
- An installation profile is a Drupal extension
(like any module) defined by a .info.yml file.
- Using inheritance we can define an installation
profile hierarchy.
- An installation profile also installs the ascending
profiles in the hierarchy.
- Can implement code or configuration that is available
to their descendants.
Requisite: Installation profile inheritance
How to
- Used by Lightning Core module, part of Acquia's
Lightning distribution.
- We need 2 patches:
-
1356276 (531)
- Allow profiles to define a base/parent
profile and load them in the correct order.
-
2914389 (8)-
Allow profiles to exclude dependencies of their
parent.
Requisite: Installation profile inheritance
How it works?
parent_profile.info.yml
name: 'Parent Profile'
type: profile
core: 8.x
install:
- module_a
- module_b
themes:
- my_theme
my_profile.info.yml
name: 'My Profile'
type: profile
core: 8.x
'base profile': parent_profile
install:
- module_c
- module_d
exclude:
- module_b
Hands-on
3.-  Installation profiles sharing a common
configuration
What is?
- Having different installation profiles that
install/import configuration from same source.
- A site can be installed from any available
installation profile and existent configuration will be
applied.
3.- Installation profiles sharing a common
configuration
Problem
core.extension.yml includes sites's
installation profile:
...
views_ui: 0
menu_link_content: 1
views: 10
my_profile: 1000
profile: my_profile
3.- Installation profiles sharing a common
configuration
Problem: Profile in core.extensions
- Installation profile in
core.extension can't be altered or
overwritten by Config Split.
- If all sites share the same configuration, all sites
should have the same installation profile.
3.- Installation profiles sharing a common
configuration
How to solve
- core.extension is a configuration
entity.
- Remove installation profile from
core.extension.yml (shared file by all
profiles/sites).
- Inject installation profile name in
core.extension configuration entity on
each site when needed.
- When exporting configuration, strip out installation
profile name.
3.- Installation profiles sharing a common
configuration
Remove installed installation profile from
core.extensions.yml
...
views_ui: 0
menu_link_content: 1
views: 10
my_profile: 1000
profile: my_profile
3.- Installation profiles sharing a common
configuration
During site installation
- Drupal triggers a validation error during
installation checks because core.extensions.yml
lacks an installation profile.
- Drupal needs the installation profile name during
installation.
3.- Installation profiles sharing a common
configuration
During site installation: validation
Patch to inject installation profile on validation
step:
3053521 (
2)-
Allow core.extension.yml to have empty profile on
install site from existing configuration
3.- Installation profiles sharing a common
configuration
During site install: actual installation
Inject installation profile during installation from the
installation profile code itself
(
hook_install_tasks_alter())
// The installation profile has been removed from core.extension.yml
// but this config is required for a complete installation.
if ($install_state['active_task'] == 'install_config_import_batch'){
$profile = $install_state['parameters']['profile'];
\Drupal::configFactory()->getEditable('core.extension')
->set('profile', $profile)
->save();
}
3.- Installation profiles sharing a common
configuration
During site life: export/import config
- When exporting configuration (cex) Drupal
would write the site's installation profile into
core.extensions.yml.
- When importing configuration (cim) Drupal
would trigger an error becuase there's no installation
profile in core.extensions.yml.
3.- Installation profiles sharing a common
configuration
During site life: export/import config
Implement a
ConfigFilter pluging to inject/remove
installation profile during configuration import/export.
/**
* Excludes installation profile from to core.extension.yml.
*
* @ConfigFilter(
* id = "MY_PROFILE_exclude_profile",
* label = "Allows to exclude the profile from core.extension.yml",
* storages = {"config.storage.sync"},
* weight = 10
* )
*/
class ExcludeProfile extends ConfigFilterBase
implements ContainerFactoryPluginInterface {
...
3.- Installation profiles sharing a common
configuration
During site life: export/import config
Method to filter out installation profile from
core.extensions.yml when exporting
configuration.
/**
* {@inheritdoc}
*/
public function filterWrite($name, array $data) {
if ($name == 'core.extension' && isset($data['profile'])) {
unset($data['profile']);
}
return parent::filterWrite($name, $data);
}
3.- Installation profiles sharing a common
configuration
During site life: export/import config
Method to inject installation profile to
core.extensions.yml when importing
configuration.
/**
* {@inheritdoc}
*/
public function filterRead($name, $data) {
if ($name == 'core.extension') {
$data['profile'] = $this->profile;
}
return parent::filterRead($name, $data);
}
Hands-on
4.- Enable config under certain conditions on
sites
4.- Enable config under certain conditions on
sites
What is?
- Allow to customize shared configuration (or apply
certain config entities from files) based on different
conditions.
- We can have specific configurations for:
- Installation profile.
- Environments.
- Site.
- Functionality.
- …
4.- Enable config under certain conditions on
sites
How to
Using the power of Config Split.
4.- Enable config under certain conditions on
sites
Config splits
- Config splits represent a certain package of
functionality (per site, per environment, per module,
etc).
- Config splits are initially disabled.
- Config splits are enabled when conditions are meet
(current site, current environment, site's profile,
installed module, etc).
- When config is imported, enabled splits "alter" the
read configuration.
4.- Enable config under certain conditions on
sites
Config splits
4.- Enable config under certain conditions on
sites
Two cases: non-Drupal condition
- Key: Drupal "bootstrap" is not
needed to check condition.
- Config splits are activated by simple
conditions.
- Common way to enable splits.
- Example: using a settings.local.php to enable by
environment.
- Example: using simple code that checks available
data, like request's domain.
4.- Enable config under certain conditions on
sites
Two cases: Drupal condition
- Key: Drupal "bootstrap" needed to
check condition.
- If Drupal is not "bootstrapped" (like in setting.php)
is too soon to run Drupal services.
- Services are needed for enabling a config split if a
module is installed (Features style).
- Relying on global variables is a bad practice.
- Solution: Enable the config splits with a configuration override service!
4.- Enable config under certain conditions on
sites
Configuration override service: how to
- Create a service that implements
ConfigFactoryOverrideInterface.
class ConfigOverrides implements ConfigFactoryOverrideInterface {
- And tell Drupal to use it!
services:
blog.overrider:
class: Drupal\blog\ConfigOverrides
arguments:
- '%container.modules%'
- '%install_profile%'
tags:
- {name: config.factory.override}
4.- Enable config under certain conditions on
sites
Configuration override service: how to
Sharing configuration multisite multiprofile
Demo 2a A!
Sharing configuration multisite multiprofile
Demo 2B!
After a long journey…
Recap
Recap
Benefits
- Configuration reuse in a multisite multiprofile
environment.
- Customized configuration based on almost any
condition.
- Build and envolve family of sites easily (or not die
trying!).
- Factories of sites.
- Drastic cost reduction in the medium to long term for
large families of sites.
Recap
Limitations
- Sites configuration must be related.
- Installation profiles must be in same hierachy.
- Complex to design the splits structure and
distribute configuration among them.
- Sites configuration can't be too customized.
- High initial cost.
Final notes
- This is a platform of related sites.
- You don't need multisite for this.
- You could use just an installation profile.
- Therefore, you don't need installation profile
inheritance.
- This is not likely to be in core. Core should stay
simple and cover many cases but no all.
Final notes
CMI 2.0
- See Roadmap
for CMI 2.
- Work in progress! Help is much appreciated!
- Three focus: improve docs, enviroment specific
configuration and cross configuration workflows.
- Config Transform import/export events that allow
subscribers to modify config.
- Experimental Configuration Environment to change
environment from command or UI.
What did you think?
Thanks!!!


Content Sources
-
VaatiVidya. (2013, March 24). Dark Souls & Implicit Game Design. Retrieved 9 September
2015 from
https://www.youtube.com/watch?v=_SOg990vAyk -
Boyd, R. (2012, September 26). Deep dungeon: Exploring the design of dark souls.
Retrieved September 9, 2015, from Gamasutra website:
http://www.gamasutra.com/view/feature/178262/
deep_dungeon_exploring_the_design_.php?print=1 -
Kain, E. (2012, December 12). The wonderful archeology of 'dark souls' lore. Retrieved
September 9, 2015, from Forbes website:
http://www.forbes.com/sites/erikkain/2012/12/12/
the-wonderful-archeology-of-dark-souls-lore/ -
Extra Credits. (2015). Side Quest - Dan Sucks at Dark Souls: The Show. Retrieved 9 September
2015, from
https://www.youtube.com/playlist?list=PLhyKYa0YJ_5DMa0bI8pwVum4SzV8U86od -
Dark souls wiki. (n.d.). Retrieved September 9, 2015, from Dark souls wiki website:
http://darksouls.wikia.com/
Image Sources
Note: All images are watermarked with links to their sources. This is simply a quality of life section so that you can find the awesome art easier!
I do not (claim to) own rights to these images. I'm purely using them in a fair-use academic setting. All rights go to their original creators/artists.


This test fetches a javascript URL via the plugin with _self as the target frame, and verifies that the call succeeds. The plugin runs within a subframe.


During the 1999-2000 academic year the Teachers College Seminar on the Future of Libraries engaged in a number of activities designed to inform the Seminar members and the broader Teachers College community about the possibilities for libraries in the years ahead. To take stock of our progress thus far members of the seminar were asked to prepare summary comments. This report consolidates those comments and summarizes the work of the seminar. The report begins by describing three roles for libraries in the future. Each of these roles will be important for research libraries in general and each has implications for the future of Milbank Library at Teachers College. Our description of these roles is not meant to suggest that they are the only roles libraries will play in the future or that these roles will displace the current roles of libraries. Rather, we present these roles to highlight the new work that is currently being done and will be done in libraries and by librarians. Following the description of the emerging roles for libraries, we present an initial set of recommendations regarding Milbank Library. The list of recommendations is necessarily incomplete, but the members of the Seminar feel confident that the recommendations we do present are sound. Finally, the appendix to the report contains the list of members of the Seminar and the highlights of the Seminar Sessions held over the spring semester. Tapes of the Seminar presentations are available for those interested in further details of any presentation.


1010 Avenue, New York, NY 10018 US.
Mon-Sat, 8.00-18.00. Sunday CLOSED
Gustave Eiffel's iconic, wrought-iron 1889 tower, with steps and elevators to observation decks.
Stay current with our latest insights
© Copyright 2018 Elixir Inc.


We use third-party cookies along with our own to enhance your user experience and provide personalized services to you on this website. We also share information about your use of our website with our analytics partners who may combine it with other information that you have provided to them or that they have collected from our use, so that Shmoop can serve you more relevant online content. By continuing to use our site, you consent to our use of cookies. For more information, see our
Privacy Policy.


My mindset prior to the ingestion of 6mg lorazepam tablets was relatively calm. Having Cyclic Vomiting Syndrom (CVS), I'm prescribed this medication through my psychiatrist and have had much experience with it, and its effects on the body at different dosages and routes of entry (IV in the hospital, for example).
The drug itself is intended to be used for a number of symptoms, including nausea, anxiety, and muscle stiffness. However, I find myself, for the most part, using it as a recreational drug instead.
*Note: Beginning at morning and continuing until the time I
consumed the lorazepam, I had taken a total of
162mg of methylphenidate by means of 3 54mg time-released
Concerta capsules (crushed to increase rate of reaction).
Prior to ingestion, I crushed the tablets up and mixed them with a drink; might as well let it dissolve quickly.
_________________________
7:30 PM - I have taken the 6mg of lorazepam on an empty stomach.
7:45 PM - Notice that my head is feeling a bit lighter and my muscules, tense from the methylphenidate, are beginning to become more relaxed.
8:15 PM - I'm feeling completely calm and content, almost warm. My visual perception has been altered. When I move my eyes, objects leave a faint trail.
8:30 PM - I insufflate another 2mg lorazepam. My vision is further altered (comparable to an alcohol buzz) and time seems to have slowed. Walking around, I feel completely free of all anxiety and a bit drowsy.
9:30 PM - After an hour, I'm still feeling the same effects, but they are slightly diminished. I would assume that the methylphenidate allows for the lorazepam effects to be exhacerbated and extended to some degree.
10:30 PM - The apex of the experience is just about done and I'm left still feeling relaxed as ever and I will for another 4 hours, given the half-life and properties of th medication. A general, recommended dose should last about 6 hours before readministration is needed, on average, depending upon the weight and type of the individual taking the drug.
In retrospect, this was a well done and worth-while experiment. I highly recommend the combination of both the methylphenidate and lorazepam. However, just the lorazepam alone should be plenty to keep you occupied and interested. The primary benefit of using the methylphenidate and lorazepam together is that you can get the desired effects from the lorazepam, with the omission of the fatigue -- which is combatted by the methylphenidate.
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.


New York City Double Feature Film comment by Mark R. Leeper Copyright 1989 Mark R. Leeper
I came out of a double feature at the Film Forum in New York City listening to the conversation of the couple behind me. "Boy, I guess you really don't know how bad films were back then," the man said. I guess the comment really took me by surprise. This was an evening I had been looking forward to for months and which had surpassed all expectations. The evening started with a chapter from the serial BATMAN, continued with DELUGE, and concluded with F.P.1. Each was a film I'd wanted to see for years. The fact that they did not stand up well compared to THE ABYSS is hardly relevant. Each of these films is a missing piece of the puzzle of how science fiction films evolved. When they find a new fossil at Olduvai they don't get excited because it came from a really terrific ape. Of the great classic science fiction films that I have never seen, I expect them all to be at best mediocre by today's standards. Better than that is too much to hope for. I frankly never expect to see a great 1930s science fiction film that I have not already seen.
The BATMAN serial was not actually from the 1930s, but from 1943, and directed by Lambert Hillyer, who had previously directed atmospheric chillers such as THE INVISIBLE RAY and DRACULA'S DAUGHTER. Lewis Wilson was the screen's first Batman (succeeded by Robert Lowry and, of course, Adam West and Michael Keaton). I have seen Michael Keaton sticking his chin out of his stiff--probably plastic--costume, and he really looks like the comic character. In 1943 Columbia did not have the same materials. Wilson's Batman suit really does look like the long underwear it was probably made from. There are wrinkles on the legs and the arms. There is a pressed crease up the side of the legs. The cowl has the bat-ears but they are bent at the ends. The effect is like a jester's cap and brought howls of laughter from the audience. Robin had a full head of curly hair and a Halloween mask.
The only recognizable actor in the episode was J. Carrol Naish as the evil Japanese mad scientist Dr. Daka with a machine that turns men into zombies. When Daka turns on his weird electrical equipment the entire theatre vibrates, probably due to equipment left over from showing THE TINGLER earlier the same week. It wasn't as visually impressive as the 1989 BATMAN, but it was a lot more fun. This was Chapter Five of BATMAN, for the record.
Film number two was DELUGE, directed in 1933 by Felix Feist, then 23 years old. He directed the 1953 DONOVAN'S BRAIN and several episodes of television's VOYAGE TO THE BOTTOM OF THE SEA. Here he was directing a screen version of the novel by S. Fowler Wright. It should be noted that DELUGE has long been thought to be a lost film and remains semi-lost. It has been just a couple of years since a copy turned up and it is dubbed in Italian. For this showing a man at the back of the theatre translated.
The film opens by reminding us that God promised not to destroy the world by flood again and then, after a buildup of nature going very sour, proceeds to show most of the world being destroyed just the same way again. We are told that the west coast has fallen into the ocean but never see it. We do see New York City struck down by tidal waves and we see buildings crumble. If the effects were believable they would be spectacular. However, even a contemporary reviewer complained that the effects were none too convincing. My audience apparently agreed and jeered. Now I like really credible effects. They are a virtue. But a reasonable attempt at effects is sufficient for me. They are, after all, just a device to carry the plot. When I go to a puppet show I do not complain that the puppets do not fool me into thinking they are real people. Weak effects are quite forgivable as far as I am concerned if the rest of the film captures my interest.
And DELUGE is a very interesting film, if not for anything intrinsic at least for where it fits historically. What is particularly interesting is how the film reminds one of films that came after, but not of films that came before. After the holocaust is over and there are just a handful of people left the story has definite parallels to NO BLADE OF GRASS and the excellent British television series THE SURVIVORS.
Before the holocaust we have been introduced to iron-jawed Martin (Sidney Blackmer), a family man who saves his family by moving them to a stone quarry but is somehow separated from them. And we meet Claire, an athletic swimmer. The storm washes Claire to the doorstep of two criminals. Claire becomes one vertex in a triangle that leads to the murder of one of the criminals. Roger Corman would use almost the same plot for the 1960 LAST WOMAN ON EARTH.
Claire escapes the killer Jephson only to be found by Martin, alone since the storm. The two of them try to survive together. However, in the mean time, a group of survivors has set up a small town. They have thrown out some undesirables and the criminals pick Jephson as their leader. He leads them on a raid against Martin and Claire. At this point the film has sort of degenerated into a bad Western plot. Surprisingly, things do *not* work out well for all concerned, and the film does at times touch on questions of whether bigamy is justifiable in a post-holocaust world. The story if crudely done, but that didn't stop much of it from being redone, often no better, by other filmmakers. A good film? No. But not a bad film either and definitely an important artifact.
Waiting for the film to start, I started talking to someone sitting next to me who had just finished seeing F.P.1. He assured me it really cornball with bad dialog. I think I'd like to thank him for lowering my expectations and making F.P.1 such a pleasant surprise when my turn came to see it. F.P.1 (1932) is an engineering film, sort of a forerunner to THE TUNNEL and its remake THE TRANSATLANTIC TUNNEL, and later THINGS TO COME. Like the Tunnel films, F.P.1 concerns itself with engineering feats to aid transatlantic travel. Instead of being about a tunnel, it is about the building of a great floating airstrip and hotel to be built mid-Atlantic, the Floating Platform 1.
F.P.1 is really a German film refilmed in English to give it the trappings of a British film. It is the story of engineer Captain Drost, who designed the platform but could not sell it to anyone, and his friend pilot Major Ellissen, an enigmatic figure who arranges stunts to bring the platform to the attention of a shipyard, then competes with Drost for the attentions of heiress Clare Lennartz. Ellissen is played by a very dashing Conrad Veidt.
F.P.1 is a spectacular melodrama of a great engineering feat and what goes into building it. There is a subplot of a consortium dedicated to destroying the great platform for no readily apparent reason.
I am glad I went.
Mark R. Leeper att!mtgzx!leeper<EMAIL_ADDRESS>.
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


--- status: "draft" title: "Disabled text input" text: Disabled input elements are unusable and can not be clicked. This prevents a user from interacting with the input element until another action is complete. Disabled input elements in a form will not be submitted. ---


ELSEWHERE
- Designing from scratch or not?
- Illustrations on behance
CONTACT
- Email
- Github
- Linkedin
- This rap
×
THE END


Understanding Linux File Permissions
To make your server more securely, you should give minimum rights to each user. In this blog, we try to tell how basic file permissions works on linux server and how octal permissions calculated.
LINUX FILE PERMISSIONS
(-) rw-r–r– (let’s handle one of them)
(d) rwxrwxr-x
first letter means directory or file. d:directory -:file
We can seperate this file permission string to four groups: (-) (rw-) (r–) (r–)
- rw- r– r– directory or file owner group everyone
permissions owner group
drwxr-xr-x 3 root root 4096 Apr 23 20:05 ..
-rw-r–r– 1 utku utku 655 Apr 23 20:05 .profile
Octal Permissions
-rw-r–r– is equal to ‘644’ in octal permissions
r = 4 w = 2 x = 1 - = 0
rw- = 6 r– = 4 r– = 4
-rwxrwxrwx = 777 drwxr-xr-x = 755 -rw——- = 600
This file’s owner and group are named ‘utku’.
If we change group of file to ‘root’, utku user can still read file. Because owner has read access (rw-)
But if we change owner of file to ‘root’, utku user cannot read that file.
(dont forget to revert owner and group back)


--- layout: post title: Casuality Europe, Tuesday date: 2006-02-07 00:00:00 categories: business mobile play ---
Just arrived and waiting for the first talk. The event has a similar feel to dConstruct last year - quite developer-oriented, and the venue reminds me a bit of Fabrica.Jessica Tams welcomes everyone. "Casual games are easy to learn, but hard to master." Little upfront knowledge or skill needed. Can be played in a series of micro time slices potentially over a long time period. They're easy to acquire. They're platform agnostic.


Updating your company details will update them for all members of your company.
Not registered yet?
You will not be funded until you have registered with Companies House
Updating your company details will update them for all members of your company.
You will not be funded until you have registered with Companies House


Antoine Caron
cursus
projet
Antoine
CARON
Antoine CARON
Student in Computer Science
1993-01-15
Lyon, France


We are
We are a group of diverse students, in a variety of studies.
We are working together to achieve a self driving car.
Our goal is to have a basic functionaing model by the end of the semester
Our Team is comprised of 6 sub teams to complete all tasks. Project management team, front end team, sensor team, engeering team, mapping & planning team, and our professors.
In charge of documentation, communication with outside sources, and team leads.
In charge of sensor location, function, and maintnace.
In charge of path planning and decision making given information form the sensor team.
In charge of mechanical parts for the cart, and improvements needed.
In charge of the user interface that the user will use to tell the car where to go.
Our professors work with us to make sure we are meeting deadlines, and help us aquire parts as needed.
This view will display the path to get to your destination when you select it from the Location selection.
This view will display the status of the sensors.
This will display the current charge of the battery.
Will display if the GPS sensor is working.
will display if the Velodyne sensor is functioning or not.
Wil display if the Lghtware sensor is functioning or not.
Wil display if the RPLIDAR sensor is functioning or not.
Wil display if the STEAREO sensor is functioning or not.
Lorem ipsum dolor sit amet ne onsectetuer adipiscing elit. Aenean commodo ligula eget dolor in tashin ty


Happy Hour
Party Time
Delicious variety of fast foods on sale at Anitas kitchen,from all around the world prepared by one of the finest chefs.
The foods are tasty and will set you on a new food adventure path that will leave you craving for more.
Anita has a wide range of drinks from the best wines to all types of cocktails from diffrent segments of the world done
by a proffesional mixologist which is a sight to behold and inpires a classic expirience.
fastfoods
Drinks
chicken
rice
Chicken Burger
Beef Burger
Chicken Pizza
George Richard
Great food!Menu is awesome, their foods are not only great, but also in the right price. I'll highly recommend them :)
Get our daily food items delivered to your mail


GETCONTEXT
Section: Linux Programmer's Manual (2)Updated: 20 September 1999
Index Return to Main Contents
NAME
getcontext, setcontext - get or set the user contextSYNOPSIS
#include <ucontext.h>
int getcontext(ucontext_t *ucp);
int setcontext(const ucontext_t *ucp);
where:
- ucp
- points to a structure defined in <ucontext.h> containing the signal mask, execution stack, and machine registers.
DESCRIPTION
getcontext(2) gets the current context of the calling process, storing it in the ucontext struct pointed to by ucp.setcontext(2) sets the context of the calling process to the state stored in the ucontext struct pointed to by ucp. The struct must either have been created by getcontext(2) or have been passed as the third parameter of the sigaction(2) signal handler.
The ucontext struct created by getcontext(2) is defined in <ucontext.h> as follows:
-
typedef struct ucontext { unsigned long int uc_flags; struct ucontext *uc_link; stack_t uc_stack; mcontext_t uc_mcontext; __sigset_t uc_sigmask; struct _fpstate __fpregs_mem; } ucontext_t;
RETURN VALUES
getcontext(2) returns 0 on success and -1 on failure. setcontext(2) does not return a value on success and returns -1 on failure.STANDARDS
These functions comform to: XPG4-UNIX.NOTES
When a signal handler executes, the current user context is saved and a new context is created by the kernel. If the calling process leaves the signal handler using longjmp(2), the original context cannot be restored, and the result of future calls to getcontext(2) are unpredictable. To avoid this problem, use siglongjmp(2) or setcontext(2) in signal handlers instead of longjmp(2).SEE ALSO
sigaction(2), sigaltstack(2), sigprocmask(2), sigsetjmp(3), setjmp(3).
Index
This document was created by man2html, using the manual pages.
Time: 05:33:03 GMT, December 24, 2015


It can happen that you need to transfer an Application on Bitrise to another User or to an Organization. This can be done in a few seconds by following these quick steps:
- Login with the current Owner of the App on bitrise.io
- Open the App’s page and go to the
Team
tab - Make sure the new owner of the App is in the team or add her/him if you need to. In case if you want to transfer the ownership to an Organization, you have to be part of the Organization.
- Click the
Transfer ownership
button next to your name - After selecting the new owner from the dropdown, click on the purple button that says
Transfer ownership to <Username>
, and you are done!
!!! note “Good to know: Do you want to remain the connected services user?”
If you enable the Do you want to remain the connected services user?
option in the Transfer popup,
then during the transfer you’ll be explicitly marked as the “connected services” user for the app.
The "connected services" user specifies which Team Member's service connections / accounts
connected to his/her Bitrise user should be used when Bitrise tries to communicate
with another service (GitHub, Bitbucket, ...), for example to send back build status information,
or to register a new SSH key automatically.
Admins of an app can change this any time on the `Settings` tab of the app.


Introduction¶
This document will introduce you to Singularity, If you are viewing this on the web there should be links in the bar to the left that will direct you to other important topics. If you want to get a quick overview, see our quickstart. If you want to understand which commands are a best fit for your use case, see our build flow section. There is also a separate Singularity Administration Guide that targets system administrators, so if you are a service provider, or an interested user, it is encouraged that you read that document as well.
Welcome to Singularity!¶
Singularity is a container solution created by necessity for scientific and application driven workloads. Over the past decade and a half, virtualization has gone from an engineering toy to a global infrastructure necessity and the evolution of enabling technologies has flourished. Most recently, we have seen the introduction of the latest spin on virtualization… “containers”. People tend to view containers in light of their virtual machine ancestry and these preconceptions influence feature sets and expected use cases. This is both a good and a bad thing… For industry and enterprise-centric container technologies this is a good thing. Web enabled cloud requirements are very much in alignment with the feature set of virtual machines, and thus the preceding container technologies. But the idea of containers as miniature virtual machines is a bad thing for the scientific world and specifically the high performance computation (HPC) community. While there are many overlapping requirements in these two fields, they differ in ways that make a shared implementation generally incompatible. Some groups have leveraged custom-built resources that can operate on a lower performance scale, but proper integration is difficult and perhaps impossible with today’s technology. Many scientists could benefit greatly by using container technology, but they need a feature set that differs somewhat from that available with current container technology. This necessity drives the creation of Singularity and articulated its four primary functions:
Mobility of Compute¶
Mobility of compute is defined as the ability to define, create and
maintain a workflow and be confident that the workflow can be executed
on different hosts, operating systems (as long as it is Linux) and
service providers. Being able to contain the entire software stack,
from data files to library stack, and portably move it from system to
system means true mobility.
Singularity achieves this by utilizing a distributable image format
that contains the entire container and stack into a single file. This
file can be copied, shared, archived, and standard UNIX file
permissions also apply. Additionally containers are portable (even
across different C library versions and implementations) which makes
sharing and copying an image as easy as cp
or scp
or ftp
.
Reproducibility¶
As mentioned above, Singularity containers utilize a single file which is the complete representation of all the files within the container. The same features which facilitate mobility also facilitate reproducibility. Once a contained workflow has been defined, a snapshot image can be taken of a container. The image can be then archived and locked down such that it can be used later and you can be confident that the code within the container has not changed.
User Freedom¶
System integrators, administrators, and engineers spend a lot of effort maintaining their systems, and tend to take a cautious approach. As a result, it is common to see hosts installed with production, mission critical operating systems that are “old” and have few installed packages. Users may find software or libraries that are too old or incompatible with the software they must run, or the environment may just lack the software stack they need due to complexities with building, specific software knowledge, incompatibilities or conflicts with other installed programs.
Singularity can give the user the freedom they need to install the applications, versions, and dependencies for their workflows without impacting the system in any way. Users can define their own working environment and literally copy that environment image (single file) to a shared resource, and run their workflow inside that image.
Support on Existing Traditional HPC¶
Replicating a virtual machine cloud like environment within an existing HPC resource is not a reasonable goal for many administrators. There are a lots of container systems available which are designed for enterprise, as a replacement for virtual machines, are cloud focused, or require unstable or unavailable kernel features. Singularity supports existing and traditional HPC resources as easily as installing a single package onto the host operating system. Custom configurations may be achieved via a single configuration file, and the defaults are tuned to be generally applicable for shared environments. Singularity can run on host Linux distributions from RHEL6 (RHEL5 for versions lower than 2.2) and similar vintages, and the contained images have been tested as far back as Linux 2.2 (approximately 14 years old). Singularity natively supports InfiniBand, Lustre, and works seamlessly with all resource managers (e.g. SLURM, Torque, SGE, etc.) because it works like running any other command on the system. It also has built-in support for MPI and for containers that need to leverage GPU resources.
A High Level View of Singularity¶
Security and privilege escalation¶
A user inside a Singularity container is the same user as outside the container This is one of Singularities defining characteristics. It allows a user (that may already have shell access to a particular host) to simply run a command inside of a container image as themselves. The following example scenario will help illustrate a Singularity container:
%SERVER and %CLUSTER are large expensive systems with resources far exceeding those of my personal workstation. But because they are shared systems, no users have root access. The environments are tightly controlled and managed by a staff of system administrators. To keep these systems secure, only the system administrators are granted root access and they control the state of the operating systems and installed applications. If a user is able to escalate to root (even within a container) on %SERVER or %CLUSTER, they can do bad things to the network, cause denial of service to the host (as well as other hosts on the same network), and may have unrestricted access to file systems reachable by the container.
To mitigate security concerns like this, Singularity limits one’s ability to escalate permission inside a container. For example, if I do not have root access on the target system, I should not be able to escalate my privileges within the container to root either. This is semi-antagonistic to Singularity’s 3rd tenant; allowing the users to have freedom of their own environments. Because if a user has the freedom to create and manipulate their own container environment, surely they know how to escalate their privileges to root within that container. Possible means to escalation could include setting the root user’s password, or enabling themselves to have sudo access. For these reasons, Singularity prevents user context escalation within the container, and thus makes it possible to run user supplied containers on shared infrastructures. This mitigation dictates the Singularity workflow. If a user needs to be root in order to make changes to their containers, then they need to have an endpoint (a local workstation, laptop, or server) where they have root access. Considering almost everybody at least has a laptop, this is not an unreasonable or unmanageable mitigation, but it must be defined and articulated.
The Singularity container image¶
Singularity makes use of a container image file, which physically includes the container. This file is a physical representation of the container environment itself. If you obtain an interactive shell within a Singularity container, you are literally running within that file. This design simplifies management of files to the element of least surprise, basic file permission. If you either own a container image, or have read access to that container image, you can start a shell inside that image. If you wish to disable or limit access to a shared image, you simply change the permission ACLs to that file. There are numerous benefits for using a single file image for the entire container:
Copying or branching an entire container is as simple as
cp
Permission/access to the container is managed via standard file system permissions
Large scale performance (especially over parallel file systems) is very efficient
No caching of the image contents to run (especially nice on clusters)
Containers are compressed and consume very little disk space
Images can serve as stand-alone programs, and can be executed like any other program on the host
Copying, sharing, branching, and distributing your image¶
A primary goal of Singularity is mobility. The single file image format makes mobility easy. Because Singularity images are single files, they are easily copied and managed. You can copy the image to create a branch, share the image and distribute the image as easily as copying any other file you control!
If you want an automated solution for building and hosting your image, you can use our container registry Singularity Hub. Singularity Hub can automatically build Singularity recipe files from a GitHub repository each time that you push. It provides a simple cloud solution for storing and sharing your image. If you want to host your own Registry, then you should check out Singularity Registry. If you have ideas or suggestions for how Singularity can better support reproducible science, please reach out!.
Supported container formats¶
squashfs: the default container format is a compressed read-only file system that is widely used for things like live CDs/USBs and cell phone OS’s
ext3: (also called
writable
) a writable image file containing an ext3 file system that was the default container format prior to Singularity version 2.4directory: (also called
sandbox
) standard Unix directory containing a root container imagetar.gz: zlib compressed tar archive
tar.bz2: bzip2 compressed tar archive
tar: uncompressed tar archive
Supported Uniform Resource Identifiers (URI)¶
Singularity also supports several different mechanisms for obtaining the images using a standard URI format.
shub:// Singularity Hub is our own registry for Singularity containers. If you want to publish a container, or give easy access to others from their command line, or enable automatic builds, you should build it on Singularity Hub.
docker:// Singularity can pull Docker images from a Docker registry, and will run them non-persistently (e.g. changes are not persisted as they can not be saved upstream). Note that pulling a Docker image implies assembling layers at runtime, and two subsequent pulls are not guaranteed to produce an identical image.
instance:// A Singularity container running as service, called an instance, can be referenced with this URI.
Name-spaces and isolation¶
When asked, “What namespaces does Singularity virtualize?”, the most appropriate response from a Singularity point of view is “As few as possible!”. This is because the goals of Singularity are mobility, reproducibility and freedom, not full isolation (as you would expect from industry driven container technologies). Singularity only separates the needed namespaces in order to satisfy our primary goals.
Coupling incomplete isolation with the fact that a user inside a container is the same user outside the container, allows Singularity to blur the lines between a container and the underlying host system. Using Singularity feels like running in a parallel universe, where there are two time lines. In one time line, the system administrators installed their operating system of choice. But on an alternate time line, we bribed the system administrators and they installed our favorite operating system and apps, and gave us full control but configured the rest of the system identically. And Singularity gives us the power to pick between these two time lines. In other words, Singularity allows you to virtually swap out the underlying operating system for one that you’ve defined without affecting anything else on the system and still having all of the host resources available to you.
The container is similar to logging into another identical host running a different operating system. e.g. One moment you are on Centos-6 and the next minute you are on the latest version of Ubuntu that has Tensorflow installed, or Debian with the latest OpenFoam, or a custom workflow that you installed. But you are still the same user with the same files running the same PIDs. Additionally, the selection of name-space virtualization can be dynamic or conditional. For example, the PID namespace is not separated from the host by default, but if you want to separate it, you can with a command line (or environment variable) setting. You can also decide if you want to contain a process so it can not reach out to the host file system if you don’t know if you trust the image. But by default, you are allowed to interface with all of the resources, devices and network inside the container as you are outside the container (given your level of permissions).
Compatibility with standard work-flows, pipes and IO¶
Singularity abstracts the complications of running an application in an environment that differs from the host. For example, applications or scripts within a Singularity container can easily be part of a pipeline that is being executed on the host. Singularity containers can also be executed from a batch script or other program (e.g. an HPC system’s resource manager) natively. Some usage examples of Singularity can be seen as follows:
$ singularity exec dummy.img xterm # run xterm from within the container
$ singularity exec dummy.img python script.py # run a script on the host system using container's python
$ singularity exec dummy.img python < /path/to/python/script.py # do the same via redirection
$ cat /path/to/python/script.py | singularity exec dummy.img python # do the same via a pipe
You can even run MPI executables within the container as simply as:
$ mpirun -np X singularity exec /path/to/container.img /usr/bin/mpi_program_inside_container (mpi program args)
The Singularity Process Flow¶
When executing container commands, the Singularity process flow can be generalized as follows:
Singularity application is invoked
Global options are parsed and activated
The Singularity command (subcommand) process is activated
Subcommand options are parsed
The appropriate sanity checks are made
Environment variables are set
The Singularity Execution binary is called (
sexec
)Sexec determines if it is running privileged and calls the
SUID
code if necessaryNamespaces are created depending on configuration and process requirements
The Singularity image is checked, parsed, and mounted in the namespace
Bind mount points are setup so that files on the host are visible in the
CLONE_NEWNS
containerThe namespace
CLONE_FS
is used to virtualize a new root file systemSingularity calls
execvp()
and Singularity process itself is replaced by the process inside the containerWhen the process inside the container exits, all namespaces collapse with that process, leaving a clean system
All of the above steps are fast and seem instantaneous to the user (i.e. there is little run-time overhead), when measured on a standard server the overhead was approximately 15-25 thousandths of a second).
The Singularity Usage Workflow¶
The security model of Singularity (as described above, “A user inside a Singularity container is the same user as outside the container”) defines the Singularity workflow. There are generally two groups of actions you must implement on a container; management (building your container) and usage.
In many circumstances building containers require root administrative privileges just like these actions would require on any system, container, or virtual machine. This means that a user must have access to a system on which they have root privileges. This could be a server, workstation, a laptop, virtual machine, or even a cloud instance. If you are using OS X or Windows on your laptop, it is recommended to setup Vagrant, and run Singularity from there (there are recipes for this which can be found at the Singularity website. Once you have Singularity installed on your endpoint of choice, this is where you will do the bulk of your container development. This workflow can be described visually as follows:
On the left side, you have your build environment: a laptop, workstation, or a server that you control. Here you will (optionally):
develop and test containers using
--sandbox
(build into a writable directory) or--writable
(build into a writable ext3 image)build your production containers with a squashfs filesystem.
Once you have the container with the necessary applications, libraries and data inside it can be easily shared to other hosts and executed without requiring root access. A production container should be an immutable object, so if you need to make changes to your container you should go back to your build system with root privileges, rebuild the container with the necessary changes, and then re-upload the container to the production system where you wish to run it.
Singularity Commands¶
How do the commands work?
The following is a list of the Singularity commands, Click on each command for more information.
build : Build a container on your user endpoint or build environment
exec : Execute a command to your container
inspect : See labels, run and test scripts, and environment variables
pull : pull an image from Docker or Singularity Hub
run : Run your image as an executable
shell : Shell into your image
Image Commands
image.import : import layers or other file content to your image
image.export : export the contents of the image to tar or stream
image.create : create a new image, using the old ext3 filesystem
image.expand : increase the size of your image (old ext3)
instances : Start, stop, and list container instances
Deprecated Commands The following commands are deprecated in 2.4 and will be removed in future releases.
bootstrap : Bootstrap a container recipe
Support¶
Have a question, or need further information? Reach out to us.
About¶
Overview¶
While there are many container solutions being used commonly in this day and age, what makes Singularity different stems from it’s primary design features and thus it’s architecture:
Reproducible software stacks: These must be easily verifiable via checksum or cryptographic signature in such a manner that does not change formats (e.g. splatting a tarball out to disk). By default Singularity uses a container image file which can be checksummed, signed, and thus easily verified and/or validated.
Mobility of compute: Singularity must be able to transfer (and store) containers in a manner that works with standard data mobility tools (rsync, scp, gridftp, http, NFS, etc..) and maintain software and data controls compliancy (e.g. HIPAA, nuclear, export, classified, etc..)
Compatibility with complicated architectures: The runtime must be immediately compatible with existing HPC, scientific, compute farm and even enterprise architectures any of which maybe running legacy kernel versions (including RHEL6 vintage systems) which do not support advanced namespace features (e.g. the user namespace)
Security model: Unlike many other container systems designed to support trusted users running trusted containers we must support the opposite model of untrusted users running untrusted containers. This changes the security paradigm considerably and increases the breadth of use cases we can support.
Background¶
A Unix operating system is broken into two primary components, the kernel space, and the user space. The Kernel supports the user space by interfacing with the hardware, providing core system features and creating the software compatibility layers for the user space. The user space on the other hand is the environment that most people are most familiar with interfacing with. It is where applications, libraries and system services run.
Containers are shifting the emphasis away from the runtime environment by commoditizing the user space into swappable components. This means that the entire user space portion of a Linux operating system, including programs, custom configurations, and environment can be interchanged at runtime. Singularity emphasis and simplifies the distribution vector of containers to be that of a single, verifiable file.
Software developers can now build their stack onto whatever operating system base fits their needs best, and create distributable runtime encapsulated environments and the users never have to worry about dependencies, requirements, or anything else from the user space.
Singularity provides the functionality of a virtual machine, without the heavyweight implementation and performance costs of emulation and redundancy!
The Singularity Solution¶
Singularity has two primary roles:
Container Image Generator: Singularity supports building different container image formats from scratch using your choice of Linux distribution bases or leveraging other container formats (e.g. Docker Hub). Container formats supported are the default compressed immutable (read only) image files, writable raw file system based images, and sandboxes (chroot style directories).
Container Runtime: The Singularity runtime is designed to leverage the above mentioned container formats and support the concept of untrusted users running untrusted containers. This counters the typical container runtime practice of trusted users running trusted containers and as a result of that, Singularity utilizes a very different security paradigm. This is a required feature for implementation within any multi-user environment.
The Singularity containers themselves are purpose built and can include a simple application and library stack or a complicated work flow that can interface with the hosts resources directly or run isolated from the host and other containers. You can even launch a contained work flow by executing the image file directly! For example, assuming that ~/bin
is in the user’s path as it is normally by default:
$ mkdir ~/bin
$ singularity build ~/bin/python-latest docker://python:latest
Docker image path: index.docker.io/library/python:latest
Cache folder set to /home/gmk/.singularity/docker
Importing: base Singularity environment
Importing: /home/gmk/.singularity/docker/sha256:aa18ad1a0d334d80981104c599fa8cef9264552a265b1197af11274beba767cf.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:15a33158a1367c7c4103c89ae66e8f4fdec4ada6a39d4648cf254b32296d6668.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:f67323742a64d3540e24632f6d77dfb02e72301c00d1e9a3c28e0ef15478fff9.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:c4b45e832c38de44fbab83d5fcf9cbf66d069a51e6462d89ccc050051f25926d.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:b71152c33fd217d4408c0e7a2f308e66c0be1a58f4af9069be66b8e97f7534d2.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:c3eac66dc8f6ae3983a7f37e3da84a8acb828faf909be2d6649e9d7c9caffc28.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:494ffdf1660cdec946ae13d6b726debbcec4c393a7eecfabe97caf3961f62c36.tar.gz
Importing: /home/gmk/.singularity/docker/sha256:f5ec737c23de3b1ae2b1ce3dce1fd20e0cb246e4c73584dcd4f9d2f50063324e.tar.gz
Importing: /home/gmk/.singularity/metadata/sha256:5dd22488ce22f06bed1042cc03d3efa5a7d68f2a7b3dcad559df4520154ef9c2.tar.gz
WARNING: Building container as an unprivileged user. If you run this container as root
WARNING: it may be missing some functionality.
Building Singularity image...
Cleaning up...
Singularity container built: /home/gmk/bin/python-latest
$ which python-latest
/home/gmk/bin/python-latest
$ python-latest --version
Python 3.6.3
$ singularity exec ~/bin/python-latest cat /etc/debian_version
8.9
$ singularity shell ~/bin/python-latest
Singularity: Invoking an interactive shell within container...
 If you want to be root inside the container, you first must be root outside the container. This simple usage paradigm mitigates many of the security concerns that exists with containers on multi-user shared resources. You can directly call programs inside the container from outside the container fully incorporating pipes, standard IO, file system access, X11, and MPI. Singularity images can be seamlessly incorporated into your environment.
Portability and Reproducibility¶
Singularity containers are designed to be as portable as possible, spanning many flavors and vintages of Linux. The only known limitation is binary compatibility of the kernel and container. Singularity has been ported to distributions going as far back as RHEL 5 (and compatibles) and works on all currently living versions of RHEL, Debian, Arch, Alpine, Gentoo and Slackware. Within the container, there are almost no limitations aside from basic binary compatibility.
Inside the container, it is also possible to have a very old version of Linux supported. The oldest known version of Linux tested was a Red Hat Linux 8 container, that was converted by hand from a physical computer’s hard drive as the 15 year old hardware was failing. The container was transferred to a new installation of Centos7, and is still running in production!
Each Singularity image includes all of the application’s necessary run-time libraries and can even include the required data and files for a particular application to run. This encapsulation of the entire user-space environment facilitates not only portability but also reproducibility.
Features¶
Encapsulation of the environment¶
Mobility of Compute is the encapsulation of an environment in such a manner to make it portable between systems. This operating system environment can contain the necessary applications for a particular work-flow, development tools, and/or raw data. Once this environment has been developed it can be easily copied and run from any other Linux system.
This allows users to BYOE (Bring Their Own Environment) and work within that environment anywhere that Singularity is installed. From a service provider’s perspective we can easily allow users the flexibility of “cloud”-like environments enabling custom requirements and workflows.
Additionally there is always a misalignment between development and production environments. The service provider can only offer a stable, secure tuned production environment which in many times will not keep up with the fast paced requirements of developers. With Singularity, you can control your own development environment and simply copy them to the production resources.
Containers are image based¶
Using image files have several key benefits:
First, this image serves as a vector for mobility while retaining permissions of the files within the image. For example, a user may own the image file so they can copy the image to and from system to system. But, files within an image must be owned by the appropriate user. For example, ‘/etc/passwd’ and ‘/’ must be owned by root to achieve appropriate access permission. These permissions are maintained within a user owned image.
There is never a need to build, rebuild, or cache an image! All IO happens on an as needed basis. The overhead in starting a container is in the thousandths of a second because there is never a need to pull, build or cache anything!
On HPC systems a single image file optimizes the benefits of a shared parallel file system! There is a single metadata lookup for the image itself, and the subsequent IO is all directed to the storage servers themselves. Compare this to the massive amount of metadata IO that would be required if the container’s root file system was in a directory structure. It is not uncommon for large Python jobs to DDOS (distributed denial of service) a parallel meta-data server for minutes! The Singularity image mitigates this considerably.
No user contextual changes or root escalation allowed¶
When Singularity is executed, the calling user is maintained within the container. For example, if user ‘gmk’ starts a Singularity container, the same user ‘gmk’ will end up within the container. If ‘root’ starts the container, ‘root’ will be the user inside the container.
Singularity also limits a user’s ability to escalate privileges within the container. Even if the user works in their own environment where they configured ‘sudo’ or even removed root’s password, they will not be able to ‘sudo’ or ‘su’ to root. If you want to be root inside the container, you must first be root outside the container.
Because of this model, it becomes possible to blur the line of access between what is contained and what is on the host as Singularity does not grant the user any more access than they already have. It also enables the implementation on shared/multi-tenant resources.
No root owned daemon processes¶
Singularity does not utilize a daemon process to manage the containers. While daemon processes do facilitate certain types of workflows and privilege escalation, it breaks all resource controlled environments. This is because a user’s job becomes a subprocess of the daemon (rather than the user’s shell) and the daemon process is outside of the reach of a resource manager or batch scheduler.
Additionally, securing a root owned daemon process which is designed to manipulate the host’s environment becomes tricky. In currently implemented models, it is possible to grant permissions to users to control the daemon, or not. There is no sense of ACL’s or access of what users can and can not do.
While there are some other container implementations that do not leverage a daemon, they lack other features necessary to be considered as reasonable user facing solution without having root access. For example, there has been a standing unimplemented patch to RunC (already daemon-less) which allows for root-less usage (no root). But, user contexts are not maintained, and it will only work with chroot directories (instead of an image) where files must be owned and manipulated by the root user!
Use Cases¶
BYOE: Bring Your Own Environment¶
Engineering work-flows for research computing can be a complicated and iterative process, and even more so on a shared and somewhat inflexible production environment. Singularity solves this problem by making the environment flexible.
Additionally, it is common (especially in education) for schools to provide a standardized pre-configured Linux distribution to the students which includes all of the necessary tools, programs, and configurations so they can immediately follow along.
Reproducible science¶
Singularity containers can be built to include all of the programs, libraries, data and scripts such that an entire demonstration can be contained and either archived or distributed for others to replicate no matter what version of Linux they are presently running.
Commercially supported code requiring a particular environment Some commercial applications are only certified to run on particular versions of Linux. If that application was installed into a Singularity container running the version of Linux that it is certified for, that container could run on any Linux host. The application environment, libraries, and certified stack would all continue to run exactly as it is intended.
Additionally, Singularity blurs the line between container and host such that your home directory (and other directories) exist within the container. Applications within the container have full and direct access to all files you own thus you can easily incorporate the contained commercial application into your work and process flow on the host.
Static environments (software appliances)¶
Fund once, update never software development model. While this is not ideal, it is a common scenario for research funding. A certain amount of money is granted for initial development, and once that has been done the interns, grad students, post-docs, or developers are reassigned to other projects. This leaves the software stack un-maintained, and even rebuilds for updated compilers or Linux distributions can not be done without unfunded effort.
Legacy code on old operating systems¶
Similar to the above example, while this is less than ideal it is a fact of the research ecosystem. As an example, I know of one Linux distribution which has been end of life for 15 years which is still in production due to the software stack which is custom built for this environment. Singularity has no problem running that operating system and application stack on a current operating system and hardware.
Complicated software stacks that are very host specific¶
There are various software packages which are so complicated that it takes much effort in order to port, update and qualify to new operating systems or compilers. The atmospheric and weather applications are a good example of this. Porting them to a contained operating system will prolong the use-fullness of the development effort considerably.
Complicated work-flows that require custom installation and/or data¶
Consolidating a work-flow into a Singularity container simplifies distribution and replication of scientific results. Making containers available along with published work enables other scientists to build upon (and verify) previous scientific work.
License¶
Singularity is released under a standard 3 clause BSD license. Please see our LICENSE file for more details).
Getting started¶
Jump in and get started, or find ways to get help.
Project lead: Gregory M. Kurtzer


{{ partial "body-top" . }}
{{ partial "about.html" . }}
{{ if not (eq (len (where .Site.RegularPages "Section" "gallery")) 0) }}
{{ partial "gallery.html" . }}
{{ partial "modals.html" . }}
{{ end }}
{{ if .Site.Params.Feat.useBlog -}}
{{ if not (eq (len (where .Site.RegularPages "Section" "blog")) 0) }}
{{ partial "blog.html" . }}
{{ if .Site.Params.enforceSinglePage -}}
{{ warnf "enforceSinglePage and useBlog are both set to true. This is very likely not what you want (blog posts will always redirect to main page)"}}
{{- end }}
{{ end }}
{{ end }}
{{ partial "contact.html" . }}
{{ partial "footer.html" . }}
{{ partial "body-bottom" . }}


Working and Development In this part we modified the already created 32 bit OS.
First we will be setting up stack which is crucial to allow us to link in with C code. After that we will switch OS to 64 bit mode.
We will write C code to print any text to the screen. As I have printed SEECS created from special characters. As stack stores functions and variable used in code, we will create stacks.


BEEP BOOP
A simple program by Ernest Bruno
Begin
Let's Begin!
What is your name?
Enter a number (or numbers)!
Submit
Result:
Reverse
Return


Check out the video below to see the beautiful houses we offer. Also be sure to check out our Products page to see our top selling houses and some information about them. If you go to our Contact Us page, you can send us an email or fill out the form to learn more about the houses we offer. We're so glad you chose us to help you find the perfect home for you!
This company has helped me find a dream house everytime I have wanted to go on vacation. My family and I love working with them! - Jeannie Thomas
Excellent customer service! I've never had a problem in any of the dream houses I have rented. I even rented one for a whole year and they gave me the last month for free. I've never worked with a company that has been as amazing as Dream Houses. - Andrew Willson


Daniel D. Zhang
Software Engineer @ Facebook AI Infra
Previously: Instagram, LeetCode, Goldman Sachs
GitHub:
idf


Netsuite 2016_1
Static Public Attributes
SearchRecordBasic Class Reference
Inheritance diagram for SearchRecordBasic:
Static Public Attributes
static
$paramtypesmap
Static Public Attributes inherited from
SearchRecord
static
$paramtypesmap
Field Documentation
◆
$paramtypesmap
$paramtypesmap
static
Initial value:
= array(
)
The documentation for this class was generated from the following file:
src/Classes/
SearchRecordBasic.php
NetSuite
Classes
SearchRecordBasic
Generated by
1.8.13