| Bank | Website | Real Passwords | Two Factor Auth (TOTP) | Two Factor Auth (U2F) | Two Factor Auth (Other) | User accessible APIs |
|---|---|---|---|---|---|---|
| ANZ | www.anz.co.nz | OnlineCode SMS-based | ||||
| ASB | www.asb.co.nz | Netcode SMS or physical RSA SecureID token | ||||
| BNZ | www.bnz.co.nz | [1] | NetGuard look up table | |||
| Co-operative Bank | www.co-operativebank.co.nz | [7] | ||||
| Heartland | www.heartland.co.nz | [8] | ||||
| Kiwibank | www.kiwibank.co.nz | [2] | KeepSafe Question / Answer | |||
| RaboDirect | www.rabodirect.co.nz | [3] | [4] | Digipass hardware token | ||
| TSB | www.tsbbank.co.nz | [5] | ||||
| Westpac | www.westpac.co.nz |
Good support
Not supported, though a similar or mitigating option is
Not supported at all
No available information, if you can find out I would love to know
Q: What is a "Real Password"?
A: Passwords should be case sensitive, allow special characters, and not artificially limited in length [6]. If you have a better term for this, let me know!
Q: What is two factor authentication?
A: Two factor authentication (or 2fa) is an additional security feature used when you login to ensure that you are in control of your account. This is commonly accomplished using Time based One Time Password (TOTP) apps like Google authenticator or Physical Tokens such as Yubikeys. Click here for a more detailed introduction to multi factor authentication.
Q: Is some 2fa better than no 2fa?
A: Yes. Definitely yes. Though some methods may be more susceptible to attack than others. New sites should support industry standards such as TOTP [1] and Fido/U2F [2]. SMS is no longer recommended due to ease of exploitation.
Q: What is an RSA physical token
A: RSA SecureId tokens are a vendor specific implementation of a Time based One Time Password scheme.
Q: What do you mean by user accessible APIs?
A: (Read only) APIs that any user or company providing a service to a user can utilize to query account and spending details on behalf of a user for analytics or any other purpose, with authorization provided using a standard user-centric method such as OAuth. Think, APIs that would let products like Xero be built, to put personal data for financial analysis in the hands of users.
Not all banks had public information about password requirements.
The risk of terrible passwords can be mitigated using login analysis which all banks do. Given your password is complex enough, the probability of brute forcing it prior to your account being locked is negligible.
[1] BNZ now allow 60 character passwords! and a reasonable character range
[2] Kiwibank passwords are case insensitive (!!?) and have a maximum password length of 15 characters, with an additional challenge word on login
[3] RaboDirect appear to use a numeric PIN instead of a password for online logins, which is mitigated by [4]
[4] RaboDirect require Digipass challenge based second factor by Vasco
[5] TSB require 8-16 character passwords one letter and one number
[6] The NZ Information Security Manual (NZISM) part 2 section 16.1.21.C.01. requires passwords to be at least 10 characters, allowing lower and upper case, digits, and special characters.
[7] Co-operative bank's passworld policy requires passwords to be between 8-15 characters, containing at least 1 number and 1 letter. source
[8] Heartland Bank's passworld policy requires passwords to be between 8-15 characters, containing at least 1 number, 1 upper case letter and 1 lower case letter.


What brought me here
I have gained so much knowledge in the last 14 weeks I don't think I could write it all down. When I think back about the first week and our homework it's a massive difference. I rememebr being in the library thinking "wow this is so hard I will never know how this works". that was JUST HTML/CSS. Now we are neck deep in the back end and working toward front end proficiency. It's like night and day and when I am feeling very frustrated It gives me a lot of perspective to look back to that first study group.
My biggest accomplishment is becoming a better learner. I haven't been in school for a long time but I know that this time around I am learning so much more. I am more dedicated and diligent about this program and it is so rewarding. I have gotten better at networking, working as a group and asking questions because of this course and I know it is only up from here.
Before the first week of class even started I already wanted to quit. I started the prework and I was already lost. I was frustrated and confused and had myself convinced I wasn't cut out for this. I started from scratch, turned up my concentration and pushed thru to the first day.
Moving on to the very first week. Cue second full on breakdown. Nearly in tears in the library because I felt defeated by basic HTML and CSS. I thought - "this is the easiest part of the class and I can't even get out of the gate on it!". Once the breakthough happened it was like an addiction began. Creating something then working every line to make sure it's perfect becomes so rewarding that you don't want to stop. (Or you can't stop, depending on the project)


Howdy, Howdy, Howdy! Have you ever wanted to learn all the lines of your favorite movie or wanted to make a play out of it? You can now get any movie legally in your possesion, starring at the lowest price of $25. You can get clasics and the newset movie from each genre. We also include autographed screenplays so buy now!
Classics
Get films from the early 20th century to the end of the century
New
Get the newest films from last year!
Exclusives
Get exclusive autographed screenplays here. 100% authentic!
Create
Turn in your very own script right now. We'll make the copies and you make the profits


--- layout: post title: Android file manager quadrilemma date: '2013-01-09T17:30:15+01:00' tags: - android - file manager - astro - es file explorer - solid explorer - total commander tumblr_url: http://aladac.tumblr.com/post/40122568750/android-file-manager-quadrilemma ---
There are loads of file manager apps for Android devices. On my Android journey since version 1.0 four have gotten my attention:
In order of appearance one has kind of taken the place of another. I rarely return to Astro to see what new appeared in the most recent version. I still consider ES to be a very good (and free) tool. Mr. Ghisler’s Total Commander was the first shareware application I actually bought (of course it’s free for Android), so I had to check out the Android app too. The most recent addition is Solid Explorer which I so far consider closest to Total Commander.
All of the apps have what I expect from a mobile file manager:
I am still evaluating Solid Explorer which provides a 14 day trial. The manager is making a significant impression on me and it is highly likely I will purchase the software since it’s only around 1,5 EUR ($2).


nonnative wetland NNPI species sampled NWCA area cover plant sites (Fig. high native taxa observed population relative type National wetlands ecological Mountains percent data disturbance metrics vegetation plants site (e.g., Environmental ecoregions greater mean probability Wetland means values invasive status types Plains absolute based U.S. Western used Xeric herbaceous inland stressor-level (USEPA Ecology Table individual Coastal ecoregion ecosystem high–very USEPA conterminous woody impact importance nonnatives site-level Condition growth-habit human-mediated richness greatest Protection environmental frequency indicator low results Assessment estuarine predictor specific (). (Table Interior community {border-style Eastern Magee Plant Upper analyses categories invasion likely using exploratory number px;} stressor-levels variable #ffffff;} Nonnative Plains, West conditions extent growth natural population-weighted resource ./s--- Ecological Valleys alien analysis associated reflect sample variables western Biological Fig. Native estimated impacts n = ), stress types. Mean United addition, important patterns potential structure subpopulations survey tree North Phragmites Pyšek Supplement Wetlands australis changes described distribution field surrounding vine (S-Fig. Ehrenfeld Monitoring West, a). attributes calculated communities composition cover, d). design eastern ecoregional effects estimates groups included index scale species, subpopulations. target (Supplement ./j.-...x EPA Invasive Olsen Research Washington, abundance aquatic different graminoids having increased information introduced land processes related response richness, set soil total use Assessment. Available Herlihy Invasions Kentula Kuebbing Meyerson Office States characteristics classification ecosystems example, management occurrence provide sites, time trees type, unique varied variety vs. (see Agency. Applications Thus, adapted approximately condition describing developed diversity higher identified indicate influence invasions lower metadata model national nutrient occurring overall population-scale relationships represented sampling surveys. website: (CSV) (NWCA (~ %) ./-. ./s---. Agency Characterization Fox Global Midwest New Wiener alter annual change collab: complement dependence exceedance forbs forest given https://www.epa.gov/national-aquatic-resource-surveys/data-national-aquatic-resource-surveys. including metric million n = ) plots predictors px; recognized selected shrubs useful value varying {font-family (i.e., Accessed America Biology CIs Database Dwire Effects However, Management Midwest, Mooney NNPI, PLANTS Saltonstall Science Simberloff US, agriculture and, approach assessment b). category characterized collected combined ecoregions, ecoregions. estimate examined font-size forests frequency, future global graminoid group high) high, increasing interactions intertidal invaders level levels metrics, moderate, package physical population. possible precipitation regional riparian risk sites. > – (%) (NNPI) (~ Brewer Consequently, D.C. Estuarine July NNPI. NWCA, PRLW Phalaris Results Richardson T., Veg Vilà Water a), accuracy aggregated areas assigned available bareground co-occurring confidence considered contrast, correctly direct disturbances diverse double; elevation engineers establishment forb grass habitat herbaceous, increases indicated large locations low–moderate major moderate multiple nearly non-native occur occurrences paper part, partial plants, radius ranged regimes represent shrub spread status. strong structure, subpopulations, systems taxonomic trait traits tree/shrub types, vines water weights (Cutler (Liaw (Olsen (TXT)). (low, (~ %). (± % A., Absolute Allen American Assessment: CABI CPL Conservation Differences E., EMU Essl Hejda IPL Kentula, M., Nuñez PRLH Percent Population-weighted Relative Ricciardi Ringold Schweiger Seabloom Valleys) Valleys. XER alteration analysis, analysis. border-color border-width compared component consider description did distributed disturbance. ecoregion, entire environments evaluate expansion expected function graminoid, habit hectares however, hydrologic known listed location natives nonnatives. occurred particular pool random ranging results. season site-scale solid; somewhat species) stressors strongly study subspecies success suggest suggests version wetlands, {font-style {font-weight (Cav.) (Interior (L.) (Simberloff (Wentworth (~ . ./S-()- ./s---z Agency, Aquatic Bailey Botany Development D’Antonio Ecoregions: Estimated Greater Herlihy, Hulme In: Inland Jarošík Jr. Lonicera Mack Microstegium Nevertheless, Next, OOB Pergl Plots Population States. Steud. Stevens Tamarix Trin. WMT= [Includes abundance. abundant addition additional aid article arundinacea based. biological bold categorical category, characterization classified collaborative collection common conducted courier; cryptogenic data: debt definitions. designations disturbance, elevations em; environment evaluated examine examining exotic expand forested half human hypothetical indicators indices influenced informing invading invasibility invasions: lacustrine landscape large-scale likelihood local location, lowest methods moisture necessarily no. nonoverlapping numbers numerous outside particularly pattern plot population, predict presentation pressure propagule properties provided pt;} range reed reference reflects representing research resources respectively results, review riverine, settings shade-tolerant shallow significant site, site. small spatial standardized state state-level statistical streams stressor-level. support systems. tabular tended text thus, tidal variance vary vimineum vine, wetlands. wide widely woody, —Table ‘randomForest’


Mission
Featured Tea
Locations
Our Mission
Handpicked, Artisanally Curated, Free Range, Sustainable, Small Batch, Fair Trade, Organic Tea
Tea of the Mouth
What's Steeping at the Tea Cozy?
Fall Berry Biltz Tea
Spiced Rum Tea
Seasonal Donuts
Mytle Ave Tea
Bedford Bizarre Tea
Downtown
384 West 4th St
Suite 108
Portland, Maine


A typical data mart houses huge amount of data which grows exponentially over time. The key challenges when dealing with such data include :
Database partitioning is a feature that supports distribution of data across database partitions by using a key-hashing algorithm.
This tutorial demonstrates the data partitioning technique and highlights the best practices to do the same. The need for creating data partitions and their advantages are analysed. A graph of the query execution time against the tables with data partitioning enabled is generated and the steps to create an explain snapshot displaying partition elimination during query processing are indicated.


We use the same / similar stack for several projects:
2 stacks need to be explained:
Dev stack:
Application stack:
Dev stack: yeoman
Yeoman:
Generators that scaffold complete oppinionated projects, helping developers in starting projects quickly without the headaches that come with doing everything manaully.
Choose generator depending on Applicatoin stack
Application priorities:
are no options
The obvious trend is to have SPA's as these can give the most native feeling experience.
Another trend is to have an MVC framework as this allows us to consume REST api's.
Only 2.5 real options:
Layout frameworks:
We use bootstrap but try to lose the bootstrap feel
ES version:
We used supported version by browser (ES5)
Now we use ES6 transpiled by Babel to ES5 polyfilled for IE9/10
We need a generator that offers:
Some other things we want:
generator-gulp-angular
Install node
link7.1.0 doesn't work on windows so take the LTS release or wait till this is released.
Install globally:
npm install -g gulp bower yo
Install generator
npm install -g generator-gulp-angular
Scaffolding from an empty directory (best named after your project)
yo gulp-angular
We choose 1.5 as this is the upgrade path to 2
These can be removed or added later on
We actually don't need jQuery
Why depend on another library when we can do it ourselfs?
We use UI-router because in 1.x this was the "best" one.
As decided before we use bootstrap
C?
If we wanted to we could use Babel and still only let it accept ES5 code
Not everything needs to be different
All done
Guess what the next presentation will be about.
Lets take a quick look at the result


CCS_PG181Trans_Pos_3_4May18
LCMS
(Top 20K)
LCMS
(Top 200K)
BPI
Addnl Plots
TIC
Scan Type
Scan Count
Scan Filter Text
HMS
207
IMS
DMS
Dataset Detail Report
Dataset Info XML file


Save all of the interesting articles, videos, cooking recipes, song lyrics, or whatever else you come across while browsing. With one click, PaperKeep lets you save, read, and manage the things you find on the Internet.
PaperKeep syncs the articles and videos you save so that they’re waiting for you on all your devices - iPhone, iPad, Android, or Kindle. You can read anything you save, anywhere and anytime you want, even offline!
Find that great quote you want to remember and share?
PaperKeep makes it easy to highlight and comment on text in any article so you can easily store it, retrieve it, quote it and share it.


Select a course roster to create a separate group for that roster.
Select a role to create a separate group for that role.


Commands list
{% if commands %}
{% for command_key, command in commands %}
-
{{ command.name }}
Show Config
Prepare
{% endfor %}
{% for command_key, command in commands %}
{% include "partials/modal-config.html" %}
{% endfor %}
{% else %}
There is no available commands.
{% endif %}


User Id: Please enter a valid user id
Password: Please enter a valid password
Forgot your password or ID?
New to Sendelpe.com


Survey
Name
Favorite Food
Favorite Music
Favorite Movie
What's your date of birth?
Select your favorite color
Purple
Yellow
Submit
Here are your answers:


SYSTEM-CONFIG-PRIN(1) Man pages SYSTEM-CONFIG-PRIN(1) NAME system-config-printer-applet - print job manager SYNOPSIS system-config-printer-applet [--help] [--version] [--debug] DESCRIPTION system-config-printer-applet is a print job manager for CUPS. Normally it will display a printer icon in the notification area, greyed out when there are no print jobs for the current user. Clicking on the icon displays a simple print job manager for cancelling or reprinting jobs. To save memory, the applet waits first of all until the user has printed a job before putting the icon in the notification area. To invoke the print job manager before a job has been printed, run the applet with the --no-tray-icon option: a desktop file is provided for this, so that it should appear in the system menu. As well as displaying a printer icon in the notification area, the applet also provides a D-BUS server for the com.redhat.PrintDriverSelection interface, to help configure a new printer when it is plugged in. OPTIONS --help Display a short usage message. --version Display the version of the applet. --debug Show debugging information. AUTHOR Tim Waugh<EMAIL_ADDRESS>Author. system-config-printer 24 Nov 2010 SYSTEM-CONFIG-PRIN(1)


COURSE OUTLINE
1. Music Appreciation (this course is a basic survey of the world. Emphasis is based on the lement of music, termnologies in music, composers of music, forms of music, and style within a historical perspective)
2. Introduction to Jazz (this course introduces the origins and musical components of jazz and the contributors of its major artists.)
3. American Music (this course introduce various musical styles, influences, and composers of the United States from pre-colonal times to the present.)
4. General Music (this course emphasizes on the various musical styles, influences, and major composers around the world from pre-colonial times to the present.)
5. Ensemble I (this course provides an opportunity to perform in any combination of instrumental, vocal, or keyboard groups of two or more. emphasis is based on the development of performance skills and the study of variety of styles and periods of ensemble literature)
6. Ensemble II (this course is the continuation of ensemble 1. emphasis is based on the development of performance skills and the study of variety of styles and periods of ensemble literature)
7. Ensemble III (this course is the continuation of ensemble 2. emphasis is based on the development of performance skills and the study of variety of styles of ensemble literature)
8. Ensemble IV (this course is the continuation of ensemble 3. emphasis is based on the development of performance skills and the study of variety of styles and periods of ensemble literature)


rpc.mountd
Section: Maintenance Commands (8)Updated: 31 Dec 2009
Index Return to Main Contents
NAME
rpc.mountd - NFS mount daemonSYNOPSIS
/usr/sbin/rpc.mountd [options]DESCRIPTION
The rpc.mountd daemon implements the server side of the NFS MOUNT protocol, an NFS side protocol used by NFS version 2 [RFC1094] and NFS version 3 [RFC1813].An NFS server maintains a table of local physical file systems that are accessible to NFS clients. Each file system in this table is referred to as an exported file system, or export, for short.
Each file system in the export table has an access control list. rpc.mountd uses these access control lists to determine whether an NFS client is permitted to access a given file system. For details on how to manage your NFS server's export table, see the exports(5) and exportfs(8) man pages.
Mounting exported NFS File Systems
The NFS MOUNT protocol has several procedures. The most important of these are MNT (mount an export) and UMNT (unmount an export).A MNT request has two arguments: an explicit argument that contains the pathname of the root directory of the export to be mounted, and an implicit argument that is the sender's IP address.
When receiving a MNT request from an NFS client, rpc.mountd checks both the pathname and the sender's IP address against its export table. If the sender is permitted to access the requested export, rpc.mountd returns an NFS file handle for the export's root directory to the client. The client can then use the root file handle and NFS LOOKUP requests to navigate the directory structure of the export.
The rmtab File
The rpc.mountd daemon registers every successful MNT request by adding an entry to the /var/lib/nfs/rmtab file. When receivng a UMNT request from an NFS client, rpc.mountd simply removes the matching entry from /var/lib/nfs/rmtab, as long as the access control list for that export allows that sender to access the export.Clients can discover the list of file systems an NFS server is currently exporting, or the list of other clients that have mounted its exports, by using the showmount(8) command. showmount(8) uses other procedures in the NFS MOUNT protocol to report information about the server's exported file systems.
Note, however, that there is little to guarantee that the contents of /var/lib/nfs/rmtab are accurate. A client may continue accessing an export even after invoking UMNT. If the client reboots without sending a UMNT request, stale entries remain for that client in /var/lib/nfs/rmtab.
OPTIONS
- -d kind or --debug kind
- Turn on debugging. Valid kinds are: all, auth, call, general and parse.
- -F or --foreground
- Run in foreground (do not daemonize)
- -f or --exports-file
- This option specifies the exports file, listing the clients that this server is prepared to serve and parameters to apply to each such mount (see exports(5)). By default, export information is read from /etc/exports.
- -h or --help
- Display usage message.
- -o num or --descriptors num
- Set the limit of the number of open file descriptors to num. The default is to leave the limit unchanged.
- -N or --no-nfs-version
- This option can be used to request that rpc.mountd do not offer certain versions of NFS. The current version of rpc.mountd can support both NFS version 2, 3 and 4. If the either one of these version should not be offered, rpc.mountd must be invoked with the option --no-nfs-version <vers> .
- -n or --no-tcp
- Don't advertise TCP for mount.
- -P
- Ignored (compatibility with unfsd??).
- -p or --port num
- Specifies the port number used for RPC listener sockets. If this option is not specified, rpc.mountd chooses a random ephemeral port for each listener socket.
- This option can be used to fix the port value of rpc.mountd's listeners when NFS MOUNT requests must traverse a firewall between clients and servers.
- -H or --ha-callout prog
- Specify a high availability callout program. This program receives callouts for all MOUNT and UNMOUNT requests. This allows rpc.mountd to be used in a High Availability NFS (HA-NFS) environment.
- The callout program is run with 4 arguments. The first is mount or unmount depending on the reason for the callout. The second will be the name of the client performing the mount. The third will be the path that the client is mounting. The last is the number of concurrent mounts that we believe the client has of that path.
- This callout is not needed with 2.6 and later kernels. Instead, mount the nfsd filesystem on /proc/fs/nfsd.
- -s, --state-directory-path directory
- Specify a directory in which to place statd state information. If this option is not specified the default of /var/lib/nfs is used.
- -r, --reverse-lookup
- rpc.mountd tracks IP addresses in the rmtab file. When a DUMP request is made (by someone running showmount -a, for instance), it returns IP addresses instead of hostnames by default. This option causes rpc.mountd to perform a reverse lookup on each IP address and return that hostname instead. Enabling this can have a substantial negative effect on performance in some situations.
- -t N or --num-threads=N
- This option specifies the number of worker threads that rpc.mountd spawns. The default is 1 thread, which is probably enough. More threads are usually only needed for NFS servers which need to handle mount storms of hundreds of NFS mounts in a few seconds, or when your DNS server is slow or unreliable.
- -V or --nfs-version
- This option can be used to request that rpc.mountd offer certain versions of NFS. The current version of rpc.mountd can support both NFS version 2 and the newer version 3.
- -v or --version
- Print the version of rpc.mountd and exit.
- -g or --manage-gids
- Accept requests from the kernel to map user id numbers into lists of group id numbers for use in access control. An NFS request will normally (except when using Kerberos or other cryptographic authentication) contains a user-id and a list of group-ids. Due to a limitation in the NFS protocol, at most 16 groups ids can be listed. If you use the -g flag, then the list of group ids received from the client will be replaced by a list of group ids determined by an appropriate lookup on the server. Note that the 'primary' group id is not affected so a newgroup command on the client will still be effective. This function requires a Linux Kernel with version at least 2.6.21.
TCP_WRAPPERS SUPPORT
You can protect your rpc.mountd listeners using the tcp_wrapper library or iptables(8).Note that the tcp_wrapper library supports only IPv4 networking.
Add the hostnames of NFS peers that are allowed to access rpc.mountd to /etc/hosts.allow. Use the daemon name mountd even if the rpc.mountd binary has a different name.
Hostnames used in either access file will be ignored when they can not be resolved into IP addresses. For further information see the tcpd(8) and hosts_access(5) man pages.
IPv6 and TI-RPC support
TI-RPC is a pre-requisite for supporting NFS on IPv6. If TI-RPC support is built into rpc.mountd, it attempts to start listeners on network transports marked 'visible' in /etc/netconfig. As long as at least one network transport listener starts successfully, rpc.mountd will operate.FILES
- /etc/exports
- input file for exportfs, listing exports, export options, and access control lists
- /var/lib/nfs/rmtab
- table of clients accessing server's exports
SEE ALSO
exportfs(8), exports(5), showmount(8), rpc.nfsd(8), rpc.rquotad(8), nfs(5), tcpd(8), hosts_access(5), iptables(8), netconfig(5)
RFC 1094 - "NFS: Network File System Protocol Specification"
RFC 1813 - "NFS Version 3 Protocol Specification"
AUTHOR
Olaf Kirch, H. J. Lu, G. Allan Morris III, and a host of others.
Index
This document was created by man2html, using the manual pages.
Time: 05:34:29 GMT, December 24, 2015


Welcome to my awesome Webpage!
My favorite site is
GitHub
!
Youtube
This is a link to Youtube
Netflix
Reddit


Memory available to applications is organized in a data structure called the Global Heap. The size of the global heap may vary from machine to machine and can change from session to session, but during a single execution of GEOS, the heap size remains constant. Usually, the global heap occupies approximately 450K bytes of a 640K system.
When an application requests memory, it is allocated a "block" on the heap. Blocks may be of almost any size but may not be larger than 64K. (However, the heap is most efficient when blocks are 2K-6K in size; see Memory Etiquette .) Every block is allocated a unique handle (described below) from the Handle Table; by calling a memory manager routine, the application can translate a handle to a conventional pointer.
When GEOS shuts down, all the blocks on the global heap are freed, even if they are locked or fixed. If an application will need to store the data over a shutdown, it should make the block part of a VM file, which it can then reopen when it restores from state. The GEOS kernel attaches object blocks to system VM files and takes care of storing them to state and restoring them when GEOS restarts.
GEOS segments memory into blocks. A block is simply a number of contiguous bytes on the global heap in which code or data may be stored. Any given block may be of any size but must be less than 64K, due to the segmented addressing scheme used by the 80x86 processors. A block's size is determined when it is allocated--the process that requests the memory must specify the desired size.
To facilitate efficient memory usage and to present all applications with enough memory to function, blocks are dynamic in nature. This means that unless a block is fixed or has been locked (see Accessing Data in a Block ), there is no telling its precise address on the heap, or indeed whether it is on the heap at all. For this reason, applications are not given the address of an allocated block; rather, they are given the block's handle.
Memory handles are indexes into the global handle table. Geodes may not access the table directly. When they want to access the memory indicated by a handle, they pass the handle to the memory manager and are returned the segment address of the block's current location on the heap.
In addition to storing the actual address of the block, the handle table entry records the block's attributes, such as whether the block is discardable, swapable, or fixed. The memory manager uses all these attributes to manipulate the block.
Dynamic memory, while providing significant benefits, poses one major problem: What happens if a block is accessed while being moved, swapped, or discarded? GEOS responds to this problem with the implementation of a system for locking and unlocking blocks. When a block is locked on the heap, the Memory Manager may not move, swap, or discard it until it is unlocked. This locking mechanism allows applications to gain control over their memory during periods of access and relinquish it when it is not in active use. Applications, however, should not leave blocks locked for extended periods as this may interfere with heap compaction.
When a process wants to use a block, it instructs the memory manager to lock the block by calling
MemLock()
(see MemLock() locks a block on the heap. It is passed the handle of the block; it returns a pointer to the start of the block on the heap. If the block has been discarded, MemLock() returns a null pointer.
). The application passes the handle of the block, and the memory manager locks the block and returns a pointer to the block's area in the global heap. While a block is unlocked, the memory manager can, depending on the block's category, move the block on the heap, swap it to disk or extended/expanded memory, or discard it altogether.
When a geode requests memory, it may specify how that memory is to be treated by the memory manager. The memory request includes a set of
HeapFlags
(see HF_FIXED The block will not move from its place in the global heap until it is freed. If this flag is off, the memory manager may move the block when it is unlocked. If it is on, the block may not be locked. This flag cannot be changed after the
) which specifies how and when the block can be moved. Broadly speaking, memory blocks can be divided into four categories:
MemReAlloc()
on To change the size of a block, call the routine MemReAlloc(). This routine is also used to allocate memory for a block that has been discarded. The routine is passed the memory handle, the new size, and the HeapAllocFlags; it returns the block's
) and copy the data back from the disk. (The system takes care of reloading discarded code resources as necessary.) A block can be both discardable and swapable (indeed, discardable blocks are usually swapable). If a block has both HF_DISCARDABLE and HF_SWAPABLE set, the memory manager can either swap the block to extended/expanded memory or discard it; it will not swap the block to the disk.
Fixed blocks must be declared as such when they are allocated, and they remain so until they are freed. However, non-fixed blocks may become or cease to be discardable or swapable after they are created. To enable or disable these characteristics, call the routine
MemModifyFlags()
(see MemModifyFlags() is used to change a block's HeapFlags record. It takes three arguments: The handle of the block, the HeapFlags to turn on, and the HeapFlags to clear. It returns nothing. Not all HeapFlags can be changed after a block is created
).
Moveable, swapable, and discardable blocks are allocated from the top of the heap using a first-fit method. Fixed blocks are allocated from the bottom of the heap. If there is not enough contiguous free memory to satisfy an allocation request, the memory manager attempts to shuffle moveable blocks in order to place all free memory together in one large mass.
This shuffling is called heap compaction. If the free space resulting from compaction still is not enough, blocks are discarded or swapped to liberate more free space, and the heap is again compacted. Because of the multitasking nature of GEOS, compaction occurs in the background and is invisible to both the user and applications. The memory manager will also periodically compact memory during periods of low activity; this helps insure that there will be memory instantly available for a sudden large demand (e.g. when an application is launched).
The compaction is not arbitrary. The kernel decides which blocks to swap or discard based on recent usage patterns. This means, for example, that if you haven't used routines in a code resource for a while, that resource is more likely to be discarded than the resources you've accessed recently. (For this reason, geodes normally isolate their initialization code in one resource, which can be discarded later.)
A block left locked for extended periods could interfere with heap compaction. Suppose, for example, that the moveable locked block in the middle of the heap were left locked during an application's entire execution. Essentially, this would cause the heap to be fractured into two subheaps, making compaction more difficult and possibly slowing the system down.
All compaction, swapping, and discarding are functions of the Memory Manager. Applications need only indicate how much space is needed and when space can be freed. Applications may also resize blocks at will; if necessary, the memory manager will compact the heap to accommodate the request.
HeapAllocFlags, HeapFlags
Blocks are allocated with certain flags that help the Memory Manager manipulate memory efficiently. These flags can be found in the GEOS file heap.h , which should be included in all applications that plan to allocate memory dynamically with the memory manager routines.
The flags fall into two categories: those used when the block is allocated (stored in a record called
HeapAllocFlags
) and those used to describe the block as it is manipulated (stored in a record called
HeapFlags
).
The
HeapAllocFlags
record is used to determine what qualities the memory manager should give the block when it is first allocated. Some of these flags are also relevant when memory is being reallocated. These qualities include:
MemDeref()
( MemDeref() is passed the handle of a block on the global heap; it returns the block's address on the global heap. As noted above, this routine is useful when you allocate a fixed or locked block. If the block has been discarded, it returns a nul
) to get a pointer to the block.
Once a block is allocated, it has certain properties that govern how the Memory Manager manipulates it. These properties are determined by the
HeapFlags
. The
HeapFlags
also contain data about whether the block has been swapped or discarded. These flags are stored in the block's handle-table entry, so they can be retrieved without locking the block. To retrieve the flags, call the routine
MemGetInfo()
with the flag MGIT_FLAGS_AND_LOCK_COUNT. (See
MemGetInfo()
on MemGetInfo() is a general-purpose block information routine. It is passed two arguments: the handle of the block, and a member of the MemGetInfoType enumerated type. The return value is always word-length; however, its significance depends on th
.) Some of the flags can be changed after the block has been allocated; for details, see
MemModifyFlags()
on MemModifyFlags() is used to change a block's HeapFlags record. It takes three arguments: The handle of the block, the HeapFlags to turn on, and the HeapFlags to clear. It returns nothing. Not all HeapFlags can be changed after a block is created
. The flags include
MemModifyFlags()
.
MemModifyFlags()
.
MemModifyFlags()
.LMemInitHeap()
. It can be changed with
MemModifyFlags()
; however, an application should not change this flag.


Open Source Software (OSS) in various shapes and forms, is all about "Open the Source Code to Everyone". We want to bring the OSS concept to the next level.
Organizations like Apache Software Foundation, claims to have a Bazar of activities where everyone is jolly happy and having fun, creating code and programs to the better of human kind. The result of these activities, we all know, are genuinely good. Noone can question that. But is it necessarily the best process to go about it? We think we have identified a problem in the ASF model, and hope to show that there are other ways, and we are willing to lead the way.
At ASF, it is fun! if you are on the INSIDE. To get inside is not all that easy, but once inside you will remain. Pretty much forever, unless you resign. What does that mean? I struggle like hell, to show I am worthy and get the approval of the others on the inside, that I should be part of the fun. Once inside, I can relax, be opinion maker, make decisions, and contribute to the codebase at my leisure, if at all.
I think there is something basically wrong with this model. It is not an Open Participation model. Those who are actively working on the code, docs, PR materials, participating in the daily chores of the community and have an updated perspective of the issues at hand, should be part of the decision process. Furthermore, if I have spent the time to create a patch, I AM committed, no doubt.
- "Hi! I have created this patch that ..."
- "Jolly Good, ol' chap. Why don't you commit it into the codebase yourself?"
That means, take away the concept of commit rights. You want to join, join!. Be my guest. We are looking at the principle of Wiki applied to the code scenario. If Wiki works, why wouldn't this?
Wiki and the Open Participation Software (OPS) builds on the metaphor of "A Flock of Birds".
No individual bird in the flock sets the direction of the flock. They all sets the direction of the flock, driven by instincts of the moment in each individual. Any bird leaving the flock, is no longer a PartOf the flock and the collective decision process.
Brought on to our scene, it means that everyone that is currently part of the community, adds to the collective decision making. If I am on vacation and not staying in touch with daily issues, I am not part of the flock. When I come back from my vacation, I rejoin as a single small part of the collective mind.
Could this possibly work? Could one make a code repository open to everyone who has an interest? Wouldn't everything just deteriorate rapidly into a 'nothing'?
Interesting questions, and the same questions were raised against the Wiki concept. It has, IMO, proved the dooms-sayers wrong. It works, because everyone wants it to work. Everyone benefits, everyone enjoys the result.
But what about licensing? You can't license the code without being the owner, and for that you need Copyright assigns, indemnification agreements, ...
Do we really need a License (BSD, Apache style) that basically says "Do whatever you want with this code, as long as you don't remove the Copyrights and don't use our name(s) to promote your derived work." ? IMHO, this is a matter of Pride. If I am truly "Open", can't I just say; "Here is a bit of code, do what you like with it."? Why do I need to add, the ", BUT...".
And if one sets out with that in mind, there is actually a legal construct for this, called the Public Domain. Scientists has used it for centuries, why wouldn't it work for us? Each individual who wants to commit, needs to express the desire of no claim of Copyright. I think that can be done through the registration process, otherwise we need to require some template message saying that in the commit message for it to be accepted into the repository. This needs some legal advice.
There do exist a couple of threats to this model, but IMO the oportunities far outweighs these threats.
As far as I know, this is new, so there are no best practices yet. We need to make it work, since we want it to work, and that means willingness to adapt to the situations that will occur. However, drawing from the ASF experience I think there are some things we should consider;
People is a communicative species. It is engrain in our very existence the need to communicate, unlike for instance apes that 'groom' each other as mean of social networking. Mailing lists has many weaknesses, most importantly it has too long of feedback loop, so each post gets 'too loaded' with information and may trigger so called flame fests. I strongly believe in IRC and IM as the primary tool for communication of intent, discussions and suggestions, and the mailing list only for questions and traceability of progress.
It will become impossible for everyone to be part of everything, and many things, perhaps most things, doesn't even affect me. So if the codebase has some form of hierarchy, that is reasonably easy to understand, each individual will have different levels of interest in each leaf node, and should then monitor any changes in the codebase in the branches leading to these nodes, and take on an active review role to make sure the changes looks good. By such recommendation, more and more people will be responsible the nearer the top you get, which should ensure higher level of quality, minimizing risks of breaking compatibility, correct level of functionality and probably many other aspects of evolution.
Orthogonally to the hierarchy, which will probably be a notion and not a rule, I think it is reasonable to have some form of code ladder. Any new piece of code starts in experimental level where the piece is developed initially by one or many people, and when it is operational is promoted to preliminary level where others can actually use it. Then I think that if it attracts enough flock and they can iron out any issues, it is promoted into a optional level and becomes part of the recommended set of options to the average user. Once it is tried on the field, it may be moved up to the stable level, sending the signal to the users that there are no known issues. Finally, certain pieces could enter frozen meaning that no changes will be made, either due to an API that can't be changed or that some other system has taken its role. The question is, would the code ladder have formal requirements of development, which would require a lot of tool support, or is the flock a guarantor enough to ensure the recommendation is followed. I think the latter is sufficient.
I am talking about the similarity of Wiki spam and such, not determined attacks to shut us down. I call it spam and spammers from now on.
I think there are a couple of mechanisms that can prevent this. First of all, compared to Wiki, one needs quite a bit more knowledge in development to have subversion installed and know how to operate it against our repository.
Secondly, we have a registration system, so that we at least have a valid email address after the fact. Not much but adds a little bit.
Thirdly, we need a good notification and archiving system. I have in mind that all commits, irregardless of size, are notified to everyone, and stored in a mail archive.
Fourthly, we probably need a commandline utility which you give a svn revision number and it removes the change made from the previous revision to that one. Effectively, make it easier to revert the change than make the change.
Troublemaker is someone who is highly active in the community, but doesn't have the collective trust to be part of the collective decision making process.
My take on this at the moment is that if the "Cost of Change" is higher than the "Cost of Reversal", the collective has an extreme advantage, in that not only is it less of trouble for the individual who makes the reversal, but also the scale factor of the flock. Meaning, if a trouble making individual is trying to commit changes against the collective, he/she will soon give up, since it requires too much energy to fight the flock. Also, if the individual is gathering supporters, i.e. his/her own flock, then just point out the procedure of going through the Code Ladder and allow the fork. If it is good, the main flock will replace it when the change has matured.
You can find the origin and brief history of Open Participation Software here.


@Exported public interface HotSpotDiagnosticMXBean extends PlatformManagedObject
The diagnostic MBean is registered to the platform MBeanServer as are other platform MBeans.
The ObjectName for uniquely identifying the diagnostic MXBean within an MBeanServer is:
com.sun.management:type=HotSpotDiagnostic.* It can be obtained by calling the
PlatformManagedObject.getObjectName()
method.
All methods throw a NullPointerException
if any input argument is
null
unless it's stated otherwise.ManagementFactory#getPlatformMXBeans(Class)
| Modifier and Type | Method and Description |
|---|---|
void |
dumpHeap(String outputFile,
boolean live)
Dumps the heap to the outputFile file in the same
format as the hprof heap dump.
|
List<VMOption> |
getDiagnosticOptions()
Returns a list of VMOption objects for all diagnostic options.
|
VMOption |
getVMOption(String name)
Returns a VMOption object for a VM option of the given
name.
|
void |
setVMOption(String name,
String value)
Sets a VM option of the given name to the specified value.
|
getObjectName
void dumpHeap(String outputFile, boolean live) throws IOException
If this method is called remotely from another process, the heap dump output is written to a file named outputFile on the machine where the target VM is running. If outputFile is a relative path, it is relative to the working directory where the target VM was started.
outputFile
- the system-dependent filenamelive
- if true dump only live objects
i.e. objects that are reachable from othersIOException
- if the outputFile already exists,
cannot be created, opened, or written to.UnsupportedOperationException
- if this operation is not supported.IllegalArgumentException
- if outputFile does not end with ".hprof" suffix.NullPointerException
- if outputFile is null.SecurityException
- If a security manager exists and its SecurityManager.checkWrite(java.lang.String)
method denies write access to the named file
or the caller does not have ManagmentPermission("control").List<VMOption> getDiagnosticOptions()
writeable
VM option that can be set dynamically mainly for troubleshooting
and diagnosis.VMOption getVMOption(String name)
NullPointerException
- if name is null.IllegalArgumentException
- if a VM option of the given name
does not exist.void setVMOption(String name, String value)
getVMOption(java.lang.String)
method or
the getDiagnosticOptions()
method. This method does
not change the value of this VMOption object.name
- Name of a VM optionvalue
- New value of the VM option to be setIllegalArgumentException
- if the VM option of the given name
does not exist.IllegalArgumentException
- if the new value is invalid.IllegalArgumentException
- if the VM option is not writeable.NullPointerException
- if name or value is null.SecurityException
- if a security manager exists and the caller does not have
ManagementPermission("control").
Copyright © 2003, 2019, Oracle and/or its affiliates. All rights reserved.


A control with a content area (usually some form of text box) and an associated "Go" button
(labeled something like "Search"), where clicking the button does something with the content.
The "Go" button will be disabled until the user enters some text. Pressing
Enter at that point is equivalent to clicking the button.


Source code for Fireworks.junction
from abc import ABC, abstractmethod
from Bio import SeqIO
import pandas as pd
import Fireworks
from Fireworks.message import Message
from Fireworks.utils import index_to_list
from Fireworks.cache import LRUCache, LFUCache, UnlimitedCache
from Fireworks.preprocessing import one_hot
from abc import ABC, abstractmethod
from itertools import count
import types
import random
from bidict import bidict
import torch
import math
[docs]class Junction:
"""
A junction can take pipes as inputs, and its outputs can be piped to other pipes.
All communication is done via Message objects.
Unlike Pipes, junctions do not automatically have recursive method calling. This is because they have multiple input sources,
which would result in ambiguity. Instead, junctions are meant to act as bridges between multiple pipes in order to enable
complex workflows which require more than a linear pipeline.
"""
def __init__(self, *args, components=None, **kwargs):
if type(components) is dict:
self.components = components
# elif isinstance(inputs, Pipe): # Can give just one pipe as input without having to type out an entire dict
# self.input_sources = {'data': inputs}
elif components is None: # Subclasses can have their own method for creating an inputs_dict and just leave this argument blank
self.components = {}
else:
raise TypeError("Inputs must be a dict of sources, which can be pipes, junctions, or some other object.")
[docs]class AggregatorJunction(Junction):
"""
This junction takes multiple sources implementing __next__ as input and implements a new __next__ method that samples
its input sources.
"""
def __init__(self, *args, **kwargs):
super().__init__(*args, **kwargs)
self.check_inputs()
def __next__(self):
"""
Call __next__ on one of the input sources based on sampling algorithm until all sources run out (can run indefinetely if one
or more inputs are infinite.)
"""
# Choose which input to sample
sample = self.sample_inputs()
# Return value
try:
return self.components[sample].__next__()
except StopIteration: # Remove sample from available_inputs list
self.available_inputs.remove(sample)
if not self.available_inputs: # Set of inputs is empty, because they have all finished iterating
raise StopIteration
else: # Recursively try again
return self.__next__()
[docs] def reset(self):
for name, source in self.components.items():
source.reset()
self.available_inputs = set(self.components.keys()) # Keep track of which sources have not yet run out.
def __iter__(self):
self.reset()
return self
[docs]class RandomAggregatorJunction(AggregatorJunction):
"""
AggregatorJunction that randomly chooses inputs to step through.
"""
# TODO: Add support for weighted random sampling
[docs]class ClockworkAggregatorJunction(AggregatorJunction):
"""
AggregatorJunction that iterates through input sources one at a time.
"""
# TODO: Add support for weighted iteration and setting order (ie. spend two cycles on one input and one on another)
[docs] def reset(self):
super().reset()
self.cycle_dict = {i: name for i,name in zip(count(),self.available_inputs)}
self.current_cycle = 0


Have an Account?
Sign Up
Log In
Sign Up
Username
Password
Confirm Password
Log In
Username
Password
Lo-oK
Search
Profile
{% block content %} {% endblock %}